Extended Object Literals to review

Juan Ignacio Dopazo dopazo.juan at gmail.com
Tue Mar 15 14:52:29 PDT 2011

Absolutely not! I read the word "meme" and I panicked! Please understand
that I'm trying to write about highly technical topics in a foreign language
(I'm from Argentina), so sometimes my word choice may not be the best.

I used "classes" mostly because it's what most of JS developers I know use
today to talk about constructors. Some even talk about inheritance when just
using object composition (yes, you read right). I liked the "constructor"
keyword too. I thought it explained much better what was going on under the
hood. Too bad it is too long.

Consistency with extended object initializers makes a lot of sense. I hadn't
considered it.

Thanks for taking the time for explaining your reasoning! I'll do my best to
evangelize this vision.


On Tue, Mar 15, 2011 at 5:57 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

> 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.
> Allen
> 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/44a09506/attachment-0001.html>

More information about the es-discuss mailing list