extends keyword instead of <superclass ... >

David Herman dherman at mozilla.com
Sun Mar 27 13:44:00 PDT 2011

> Allen makes the point that class D extends B {...} may look too much like languages where it means something quite different.

Yeah, I just don't buy the argument that having different semantics should lead to different syntax: it proves too much. By definition, JS has a different semantics from other languages -- it's a different language. Are we obliged to use radically different syntax for the whole of JS? Certainly not. The point of using familiar syntax is to call out the similarities, but there will always be differences.

> 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.


I'm afraid the more radically different syntax just doesn't pass the smell test. Especially given that, as you suggest, the point is to give declarative syntax to what has always been the JS analog of the single inheritance patterns from the C++/Java world.


More information about the es-discuss mailing list