class sugar: static inheritance
allen at wirfs-brock.com
Wed Jun 8 11:50:23 PDT 2011
On Jun 8, 2011, at 9:55 AM, Brendan Eich wrote:
> On Jun 8, 2011, at 8:50 AM, Mark S. Miller wrote:
>> On Wed, Jun 8, 2011 at 8:27 AM, Brendan Eich <brendan at mozilla.com> wrote:
>>> Btw, in both C++ and Java, the semantics of "protected" is a mess, in different ways.
>> Sure. Let's not make those mistakes. Non-fixable in your view?
>> Not necessary in my view. There are all sorts of old constructs that address needs that turn out to be rare. Again, I've encountered an actual need for this only rarely, and only a mild need. As many people have said, language design largely consists of deciding to leave things out. We should do more of that ;).
> We can definitely leave protected out. My "seems inevitable" was in response to Kam bringing it up via a question that I expect will be frequently asked.
> In C++ protected is used quite a bit, judging from Mozilla's codebase. But I see fewer uses in WebKit, so there may be some old inline avoidance (prehistoric C++ compiler issues) at work in the Mozilla case.
>> Many of the things we pulled from classes to make it simple enough to get accepted -- "requires"/"abstract", traits, earlier error checking, coupling to trademarks -- are all more compelling that "protected".
Actually, I disagree with this last assertion. Protected, if done correctly, is a very important aspect of a good class design that includes inheritance.
One of the reasons that some frown on implementation inheritance, is that without some language support there are lots of ways that in can break down if both the original class designer and the subclass designer aren't careful. A great overview of these issues is the OOPSLA'92 paper by Kiczales and Lamping http://www2.parc.com/csl/groups/sda/publications/papers/Kiczales-OOPSLA92/for-web.pdf
One of their main points is that the extensibility interface that a class exposes to subclasses should be treated as a distinct interface from the interface that the classes exposes to external clients.
A concrete technique for this is the use of the template method pattern (for example, http://www.oodesign.com/template-method-pattern.html ) which is one of the GOOF patterns. In this pattern, an abstract algorithm is represented as template method with explicit this method calls at each extension point. Subclasses are expected to over-ride does methods as a means of configuring the abstract algorithm.
protected if implemented with a reasonable semantics is a way to support such reuse patterns. For example, protected provides a way to formalize the subclass extensibility contract. It is the protected methods that define that contract. Similarly, the this call-backs in a template method really define such a reusability contract and should be specified in terms of protected methods.
We are on a well trod path here. protected is an important paving stone.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss