Extended Object Literals to review

Allen Wirfs-Brock allen at wirfs-brock.com
Tue Mar 15 13:57:59 PDT 2011

The starting point for the class initialiser proposal are the Object Initialiser Extensions.  I wanted to add the option to specify the prototype for  ObjectLiteral and ArrayLiteral but because they aren't prefixed by a keyword, the extends like syntax doesn't work for them.  The <proto: foo> syntax does.  If we accept that, then it seems to make sense to use a similar convention for Class Initalisers.  Put another way, I generally prioritize internal consistency ahead of similarity with other languages.

There are both advantages and disadvantages to copying syntax from another language.  One of the disadvantages is familiar syntax creates an expectation for similar semantics.  JavaScript isn't Java and the objects defined by this proposal don't have the semantics of Java objects.  It may be a good thing if unfamiliar syntax causes a Java programmer to slow down a bit and think about what they really are defining.

At a more meta level, I don't think about this proposal as adding classes to ECMAScript. I see it as adding syntax that more directly supports a common object usage patterns.  The extension doesn't add or change ECMAScript's fundamentally instance-based object model and it doesn't preclude other patterns of object-based inheritance or composition.  That was why in earlier iterations of this proposal I used the keyword "constructor" instead of "class".

BTW, the above is mostly a mild rant in reaction to your phrase "the future of classes on Harmony".  I really hope that the meme doesn't get started that we're trying to remake JavaScript as a Java-style class-based language. I suspect you didn't mean that by the phrase, but I'm sensitive about how the things we talk about here and on the wiki are sometimes misinterpreted by members of the wider JavaScript community.   


On Mar 15, 2011, at 12:46 PM, Juan Ignacio Dopazo wrote:

> One more question about the future of classes on Harmony.
> Although the <meta: property> syntax is very clear, I'm wondering if it isn't better to be less innovative and stick to what ES4/Java/etc have been doing for a long time. Wouldn't something like this ease the learning curve of the new features?
> frozen class C extends S {
> }
> In this case frozen would apply to both the constructor, the prototype and the instances created from the class. My guess is that most developers will usually chose to apply a generic property instead of a more granular approach (sealing only the prototype, etc). Of course, this could coexist with <meta: properties> for when it is necessary to be more specific.
> class C extends S {
>   <sealed: instance>
> }
> Juan
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110315/10d4b3cf/attachment.html>

More information about the es-discuss mailing list