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. Juan On Tue, Mar 15, 2011 at 5:57 PM, Allen Wirfs-Brock <[email protected]>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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss > > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
