obsoleting the "new" keyword

Brendan Eich brendan at mozilla.com
Wed Jan 14 11:11:05 PST 2009


On Jan 14, 2009, at 10:51 AM, Peter Michaux wrote:

> On Wed, Jan 14, 2009 at 9:40 AM, Mark S. Miller <erights at google.com>  
> wrote:
>> On Wed, Jan 14, 2009 at 9:19 AM, Peter Michaux <petermichaux at gmail.com 
>> >
>> wrote:
>>>
>>> The requirement that JavaScript needed to look like Java has long  
>>> been
>>> lamented. One of the key "looks" was the "new" keyword.  Many people
>>> don't like the use of the "new" keyword. Although "new" is here to
>>> stay, could we obsolete it when using a class sugar?
>
> I should have omitted "when using a class sugar". I'd like to see
> "new" completely unnecessary.

How could that work?

new Date !== Date()

new MyFunction != MyFunction() in general


>> I agree. For *all* the desugaring of classes I've posted, the  
>> constructor is
>> merely a function, not using "this", that constructs are returns a  
>> new
>> instance. Thus, you get the same effect whether "new" is used on  
>> these or
>> not. Both "Point(3, 5)" and "new Point(3, 5)" return the same thing.
>
> Yes.
>
> Needing "new" makes some things unnecessarily bulky.
>
> var pts = getRows().map(function(r) {return new Point(r);});
>
> verses just
>
> var pts = getRows().map(Point);

As in C++, that is up to the purveyor of Point and users, who vote  
with their fingers by using some better (more usable) Point if the  
mandatory new (or lack of it) is a negative.

We are in a world of subjective value here, even though you and I know  
our object values are right ;-). The standard will not remove 'new' in  
any sense for functions of built-ins. Banning it from class  
construction expressions seems unnecessary.

If we ever hope to bootstrap built-ins (not just "native" but also  
"host", e.g. DOM) we need to allow custom new vs. invoke behavior as  
ES4's metaprogramming model allowed.


> Unfortunately some of the ES constructors behave differently when
> called without "new". This is a reasonably major problem with the
> language, in my opinion. Is there anything that can be done about this
> problem?

Not compatibly, and why are you ignoring the big difference new makes  
with user-defined functions?

/be


More information about the Es-discuss mailing list