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
