Finding a "safety syntax" for classes

Russell Leggett russell.leggett at
Wed Mar 21 08:41:32 PDT 2012

On Wed, Mar 21, 2012 at 11:12 AM, Kevin Smith <khs4473 at> wrote:

>>    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?

Agreed, table it.

> 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.

I think there's probably still wiggle room. Perhaps in the future, new()
could be added with additional semantics... Anyway, unless we are going to
really make classes distinct from functions, I'm not sure how we could
enforce super in the way you describe without affecting it in other forms.
Can you only extend classes created using "class" syntax?

- Russ

> kevin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list