Operator overloading revisited
alex at dojotoolkit.org
Mon Jul 6 18:10:14 PDT 2009
On Jul 3, 2009, at 1:21 AM, Christian Plesner Hansen wrote:
>> Likewise, for user-defined function foo, foo.prototype is writable
>> -- but
>> not so for built-in constructor functions, and not so for classes
>> as sugar
>> (more below).
> All JS code currently in existence is based on user-defined functions.
> For me that is the only case worth considering. That might explain
> the differences in our views.
> I'm not a language revolutionary, I prefer gradual evolution.
>> The original "classes as sugar" sketch Mark did to general
>> agreement at Oslo
>> included freezing the class object (constructor function) *and*
>> bind the
>> class name as a const (neither writable nor configurable in the
>> object or frame).
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? It's time to admit that built-
ins in JS are weird and that as the weirdos, they deserve to work
harder to make things happen to/for them, particularly since language
implementer code size is incomparably cheap compared to script author
Questions of "integrity" here to my mind should be justified by why
they'll be good for ALL code, not just abuse of built-ins, and then
weighed against other possible solutions. Freezing classes seems
premature to me.
More information about the es-discuss