class sugar: static inheritance

Allen Wirfs-Brock allen at
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> 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[1]. 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[2] -- 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. 

In a dynamic language such as JavaScript inheritance does not provide you subtyping guarantees. What it does provide you is a way to manage code reuse via implementation inheritance.  Some people look upon this with disdain, others think it is one of the pillars of object-oriented programming.   Whichever position you may take on that spectrum, the reality is that many application and framework designers will use ES class inheritance in this manner and that needs to be something that we factor into our design decisions (given that ES subclassing isn't subtyping it may well be the most important use case to factor into our design).

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 

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, ) 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...
URL: <>

More information about the es-discuss mailing list