Operator overloading revisited

[Brendan Eich]

On Jul 6, 2009, at 6:10 PM, Alex Russell wrote:

> This point disturbs me. Making classes frozen solves no existing JS  
> programmer problems, introduces new restrictions with no mind paid  
> to the current (useful) patterns of WRT the prototype chain, and  
> introduces the need for a const that only seems there to make some  
> weird security use-cases work. And I say that with all sympathy to  
> weird language features and the security concerns in question.
>
> Why should this stuff be the default?

What Mark said, I agree completely with his post: "this stuff" is  
*not* "the default" -- function as constructor is the default, and no  
one is salting that syntax. So why are you against sugar for high- 
integrity programmers? It's not as if those weirdos will take over the  
world, right?

If you're worried that the 'class' keyword will hypnotize the masses  
into locking things down overmuch, then you don't trust the masses  
very much. They'll mostly avoid new stuff, and any who get burned by  
inability to monkey-patch (which is *not* an unmixed blessing) will  
retreat, and probably start a "don't use 'class'" movement.

This is not 'final' in Java (which pace Mark, I believe was overused,  
including in the standard library, but which also has different enough  
semantics that I wouldn't drag it in here as a precedent. We're  
talking about sugar for ES3 and ES5 facilities already implemented, or  
nearly implemented. There was no such underlying metaprogramming API  
prefiguring final in Java, AFAIK.

There should be sugar for high- and low-integrity programmers, and  
then they can get back to their standoff. :-/

/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20090706/5a0492f8/attachment.html>