extends keyword instead of <superclass ... >

Brendan Eich brendan at mozilla.com
Sun Mar 27 13:05:13 PDT 2011


On Mar 27, 2011, at 11:33 AM, Juan Ignacio Dopazo wrote:

> On Sat, Mar 26, 2011 at 6:31 PM, Dmitry A. Soshnikov <dmitry.soshnikov at gmail.com> wrote:
> Why not just to use already reserved `extends` keyword for specifying a superclass? These XML-like braces looks not so elegant.
> 
> I asked this question a couple of days ago. The answer is quite simple. Object initializer extensions are more than just constructor syntax. They allow you to create complex objects without all the hassle in (function(){}()). So the constructor syntax was made this way to be consistent with object initializer syntax.

The meta syntax (e.g., var obj = {<proto: p>, key: val}) is not inconsistent with initialisers, it's an extension to them. But it's not the only self-consistent extension. Dmitry mentioned letting the meta properties appear to be regular key: value pairs but distinguishing the keys with @ or #.

Allen makes the point that class D extends B {...} may look too much like languages where it means something quite different. That's true, but I am not sure JS should be so special that it seems to mix bits of those languages into one (of several conceivable) extensions to initialiser syntax:

class D {<superclass B>};

Whatever you think of the meta section, the leading 'class D {' telegraphs influence from, and just familiarity with, those other languages. And I don't think that is a bad thing even if semantics differ.

Just changing 'class' to 'constructor' (adding a new perhaps-only-contextually reserved word, and a long one at that) is not the issue. Sure, doing that would in a text-only way make the syntax not look like any other language, exactly. But ignore the skin: the bones look familiar, going back to C structs.

Now add some notion of inheritance and you're following the C++ "body plan".

Do we really need to look different yet still have bones that look so familiar? I am not convinced.

The strongest case for extending initialiser syntax is that it is "nearly declarative" today. That suggests strongly making the extension fully declarative, i.e., not usable as an expression. And that, all else equal (never is, but:) says to consider class D extends B {...}. My 2 cents.

/be

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110327/73ed5625/attachment.html>


More information about the es-discuss mailing list