Operator overloading revisited
brendan at mozilla.com
Mon Jul 6 20:04:10 PDT 2009
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
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. :-/
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss