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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
