> 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.
+1
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.
Dave
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
