Kevin Smith wrote:
I think it's arguable either way. I mean, the initializer-only behavior
advocated by Allen et al makes the class useless when called (as opposed
to new'd).
I don't think such an opinionated approach is really necessary. One can
account for the funky behavior of the built-ins by providing an
additional "call" hook on the class, and leave everything else as is.
When the class is called (as opposed to new'd), it would use that hook
instead of the constructor. ("super()" would still use the parent's
constructor function.)
It could be supported with syntax like so:
class C {
static(...args) { /* call behavior */ }
}
Read my reply to Allen, it shows more general solution there. In a few
words, with class and constructor separated, you can specify what object
should represent the class (and is given appropriate .prototype and
[[Construct]]), would you want to (otherwise, plain object is created
for you). One of the options is you can specify that a function should
represent it:
class C {
static function(...args) { /* call behaviour */ };
}
though you can of course put any expression there. Another good
candudate is {...} object literal.
I think one could also make a case that the default behavior for such a
hook would be to "new" the class, as some built-ins do (and as many
current JS "classes" attempt to do):
class C {
static(...args) { return new C(...args); }
}
Yeah, in my proposal there is no default [[Call]] (have no reason for
general object). But it is more general.
This seems like a pretty clean design to me.
{ Kevin }
Herby
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
