obsoleting the "new" keyword

Brendan Eich brendan at mozilla.com
Sun Jan 18 16:35:48 PST 2009

On Jan 17, 2009, at 12:51 PM, Peter Michaux wrote:

> In order to be able to do the following, the Point.new function would
> need to be bound to Point and that is not the way properties work in
> JavaScript (which is unfortunate in some cases but beneficial in
> others.)
> var pts = getRows().map(Point.new);
> When Point.new is called inside map, the "this" object will be the
> global object, not the Point object.

Does the |this| object matter? It need not, but if it did, then the  
following should help.

People bind |this| all the time, and ES3.1 has  
Function.prototype.bind. It's not hard to imagine extending this to  
classes and defining new as a bound method of a class or function.

We also allow keywords as property names in JS1.7+ and did for ES4 --  
this relaxation from current context-free reservation of identifiers  
has been talked about for 3.1 too, and IIRC it was agreed to for  
Harmony at last summer's Oslo meeting.

With the meta-programming APIs (Object.defineProperty, etc.) in ES3.1,  
combined with JS1.7-ish keyword reservation, you could define such a  
class new method:

// Assume classes as sugar definition of class C
Object.defineProperty(C, 'new',
                       { enumerable: false, configurable: false,  
writable: false,
                         value: function () { return C.apply(null,  
arguments); }.bind(C) });

Of course this seems like much ado about nothing, because classes as  
sugar mean C is a factory function, so you could just write

var pts = getRows().map(Point);

Again, if the class always constructs when invoked, why do we need .new?

One answer might be for classes that do not construct when invoked.  
For better or worse, the core language and common embedding objects  
have class constructor functions that do not construct when invoked  
without operator new.


More information about the Es-discuss mailing list