The class operator: a bridge between object and function exemplers

Russell Leggett russell.leggett at gmail.com
Tue Nov 15 16:08:09 PST 2011


On Nov 15, 2011, at 5:45 PM, Brendan Eich <brendan at mozilla.com> wrote:

> On Nov 15, 2011, at 10:34 AM, Russell Leggett wrote:
> 
>> Yes, of course you're right about that. There was something in the back of my brain saying there might be a problem with that optimization, but I had hoped it could be done, because that is probably the most common case.  I suppose you could say that it isn't an optimization, but simply part of the semantics. Not sure if that would be confusing or just seem like the right behavior.
> 
> Semantics that sometimes make a new object with the given operand as its proto, other times return the operand unobservably mutated, are not gonna fly. That's bad for human and robot readers (i.e., implementations).

Fair enough. It loses some of its elegance in the common case, but not to the point that it becomes inelegant in my mind. Certainly when you even have to take into account the difference between an object literal with and without a constructor, always creating a new object is best.

At this point, since it seems to me easy enough to implement as a function, is there a reason to go all the way to an operator. I think if you include the ability to have a declarative style with a name, then it pushes it over the top from a little sugar, to a comfortable familiar syntax.

   class Point {...} //constructor has the correct name, Point is a declared variable
   //vs
   let Point = class {...}

- Russ


More information about the es-discuss mailing list