why not "new" instead of "constructor"?

Jake Verbaten raynos2 at gmail.com
Sat Nov 19 09:42:45 PST 2011


> let Point = class {
>    x: 0,  //not really needed unless defining an object exemplar
>    y: 0,
>    new(x,y) {
>       this.x = x;
>       this.y=y;
>    }
> };

Yes this is better, could we go one step further and allow for


to work instead of new Point(1,2).

If we just make the "new" method property create an instance of Point and
pass that in as the this value then it would solve the need for having new

This would behave similarly to selfish's .new function.

The only issue is that all code that checks obj.constructor for the link
will break because we no longer link the constructor anymore.

> It is shorter to type, reads better, and is much more suggestive of its
> direct relationship with the new operator.
> The only real issue I can think of is that in ES5 unquoted "new" is a
> valid property name in an object literal.  However, in this case we are
> using it in a new syntactic context (a concise method property) that
> doesn't exist in ES5.  Whether or not we also let gave new this meaning in
> a propertyAssignment form (a breaking change) can be a secondary design
> decision to be considered.  Related would be concern that there are
> frameworks that actually use obj.new() as an idiom.  We probably would need
> to be careful to not break those, but I think that is also doable.
> There are various semantic details that need to be specified, but none of
> them seem difficult.  Before getting into them, I'm more interested in what
> is essentially a bikesheding questions:  is this a direction that we shoud
> consider?
> allen
> _______________________________________________
> 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/20111119/aa0c594c/attachment.html>

More information about the es-discuss mailing list