obsoleting the "new" keyword

Brendan Eich brendan at mozilla.com
Mon Jan 19 13:56:35 PST 2009


On Jan 19, 2009, at 10:27 AM, Peter Michaux wrote:

>> 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.
>
> That is the answer.

Then how does one program what such classes do when they are invoked?  
One would have to write C.new and C as a function:

class C(a, b) {
   static function new() {
     // constructor here...
   }
   // other methods here...

   // Code for C invoked as a function here:
   return String(a) + b;
}

At the Kona meeting we sketched alternatives for static public  
methods. I'm using one such here (implicitly public), but the syntax  
is not important -- except note how allowing reserved identifiers  
after 'function' is important so that C.new can be called later.


>> For
>> better or worse, the core language and common embedding objects  
>> have class
>> constructor functions that do not construct when invoked without  
>> operator
>> new.
>
> By "obsolete" the "new" operator, I did not mean remove it from the
> language. I meant make using "new" the less preferred way

There's nothing short of removing new to make it less preferred than  
some lengthier and more punctuated syntax, whatever your preference  
might be.


> to have a
> constructor function work as a constructor rather than a regular
> function call. In order to make "new" the less preferred way, a
> uniform way (possibly like String.new and Point.new) could be added to
> the language so that the "new" operator can stay in place but would be
> "community deprecated". Does that make sense?

Not really. First, there's a ton of new based code and books out  
there. Second, other languages favor new C over C.new (counterexamples  
exist but they won't move the entire community, or even a majority, as  
far as a I can tell). Thirs, (new C) and (new C(a, b)) are as short as  
if not shorter than (C.new()) and (C.new(a, b)). This plus the lighter  
visual weight due to space instead of dot means operator new will  
perdure -- I'll bet real money on it.

But again, since we can't remove operator new, there's not much point  
in side bets or speculation. We should talk about metaprogrammability  
-- invoking vs. constructing, the straw syntax shown above, etc.

/be


More information about the Es-discuss mailing list