Finding a "safety syntax" for classes

Kevin Smith khs4473 at gmail.com
Wed Mar 21 08:12:29 PDT 2012


>
>
>    1. I think its easier to explain - it will actually result in a
>    constructor on the prototype.
>    2. The actual constructor function and the .constructor property
>    really should always be in sync - this helps with that.
>    3. "new" doesn't have those benefits - people might expect to be able
>    to call .new() like in ruby.
>    4. "new" conflicts with the new <object> proposal.
>
> There are some minor practical considerations on the "constructor" side,
and aesthetic considerations on the "new" side.  Instead of squaring off
now, can we just agree to leave if off the table temporarily?

I think that's ok. Just like I don't think there should be an implicit
> super call at the top of the constructor if you skip it. Sure Java and C#
> enforce this, but I don't think its really the JavaScript style. There are
> realistic use cases for doing something before you call super, or skipping
> a call to super.
>

I can basically agree with you (although I don't see a use case for
skipping the super constructor).  But because of ordering requirements this
is going to shut the door forever on instance field initializers.  Nothing
necessarily wrong with that, we just need to be aware.

kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120321/69265156/attachment.html>


More information about the es-discuss mailing list