Thoughtful, well-written article. Thanks! It brings up a couple points.
First, I hadn't heard of BETA. It's always interesting to see language choices that didn't survive, for whatever reason.
Second, I agree with the statement, "What this means is that the subclass is in control of the dispatch chain...This is great for flexibility, but as an API designer, that can be frustrating."
But I don't agree that's a problem. Isn't the need for the subclass to be in control the more frequent use case? I would be shocked / upset at a language that made it the other way around. You have to support both. You probably want the implementer of the subclass to have maximum freedom and to decide what's appropriate, because you can't anticipate all possible implementations.
The following two paragraphs, "There’s an implied requirement here...how are you supposed to know that you need to do that? You can document it, but it would be better if the base class itself made sure you did the right thing" aren't convincing to me. For one thing, maybe I don't want the call to setTransform in my implementation. Or maybe I want to setTransform(x - 1, y - 1). Also, to answer "how are you supposed to know...?" Maybe by reading the code. Why would you even need to document it? If you are extending a class, you have to read its code to even know if it's a good idea.
The example of the render method with an abstract onRender method is good for many use cases of this. How is this more difficult than using the proposed "inner" keyword? The "inner" approach doesn't seem to me to have less code or to be easier to understand. When I imagine how inner would work ("...specialize the behavior of their superclasses at well-defined points (i.e. at calls to inner...") it didn't seem to be any different than the super keyword in practice.
There's also many other options that may be more appropriate depending on the context. Someone in the comments pointed out that maybe interfaces and inversion-of-control would be better. There are also a variety of different patterns available that achieve the same thing depending on the context. The Decorator pattern might be another one. If you always want all GameObjects to be transformed in a game, for instance, one approach that would work fine is to only render objects of type "Renderable" and perhaps you wrap all GameObject instances in a decorator of type Renderable, which calls setTransform and then calls the onRender of the wrapped object.
Like I said, that's just one other option.
At the end of the article, I'm left scratching my head a bit at the title. It would be more "impolite" to me if the person who created a given base class
a) required me to extend their base class in order to achieve something in the program; and
b) also required that super be called at a specific point in any overridden methods
One small nit that's neither here nor there: in Java methods marked final can't be overridden so maybe the example code with the protected abstract onRender method should have a "final void render..." method.
First, I hadn't heard of BETA. It's always interesting to see language choices that didn't survive, for whatever reason.
Second, I agree with the statement, "What this means is that the subclass is in control of the dispatch chain...This is great for flexibility, but as an API designer, that can be frustrating."
But I don't agree that's a problem. Isn't the need for the subclass to be in control the more frequent use case? I would be shocked / upset at a language that made it the other way around. You have to support both. You probably want the implementer of the subclass to have maximum freedom and to decide what's appropriate, because you can't anticipate all possible implementations.
The following two paragraphs, "There’s an implied requirement here...how are you supposed to know that you need to do that? You can document it, but it would be better if the base class itself made sure you did the right thing" aren't convincing to me. For one thing, maybe I don't want the call to setTransform in my implementation. Or maybe I want to setTransform(x - 1, y - 1). Also, to answer "how are you supposed to know...?" Maybe by reading the code. Why would you even need to document it? If you are extending a class, you have to read its code to even know if it's a good idea.
The example of the render method with an abstract onRender method is good for many use cases of this. How is this more difficult than using the proposed "inner" keyword? The "inner" approach doesn't seem to me to have less code or to be easier to understand. When I imagine how inner would work ("...specialize the behavior of their superclasses at well-defined points (i.e. at calls to inner...") it didn't seem to be any different than the super keyword in practice.
There's also many other options that may be more appropriate depending on the context. Someone in the comments pointed out that maybe interfaces and inversion-of-control would be better. There are also a variety of different patterns available that achieve the same thing depending on the context. The Decorator pattern might be another one. If you always want all GameObjects to be transformed in a game, for instance, one approach that would work fine is to only render objects of type "Renderable" and perhaps you wrap all GameObject instances in a decorator of type Renderable, which calls setTransform and then calls the onRender of the wrapped object.
Like I said, that's just one other option.
At the end of the article, I'm left scratching my head a bit at the title. It would be more "impolite" to me if the person who created a given base class
a) required me to extend their base class in order to achieve something in the program; and b) also required that super be called at a specific point in any overridden methods
One small nit that's neither here nor there: in Java methods marked final can't be overridden so maybe the example code with the protected abstract onRender method should have a "final void render..." method.