Operator overloading revisited

[Alex Russell]

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  
>> binding
>> 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  
code size.

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.

Regards