Brendan Eich wrote:
Herby Vojčík wrote:
In a few words, with class and constructor separated, you can specify
what object should represent the class
Why? Where are the use-cases driving this, which goes beyond class as
constructor function that can be called as well as new'ed?
This question is unfair: no one have "use cases" for this, when it was
not possible at all in the language.
I'd ask the contrary*: what are the use case of tying class with its own
constructor function?
*given the virtual scenario where those two are not tied
(and is given appropriate .prototype and [[Construct]]),
By mutation of the result of an evaluated expression?
Good question.
Well, that "static Expr;" was the second step, a possible cowpath when
you allow the cows visit those green pastures beyond class tied to the
constructor. So don't take it (the static syntax) as true proposal.
But to answer, yes, by modifying it.
In case of {....} literal object, it's fine; no problem.
In case of function (...) {...} (or (...) => {....}) also no problem: it
is fresh creation and its [[Construct]] and .prototype may be changed
accordingly.
In case of any other expression: you've been warned, but if you really
want, you can (in case you put already existing "class-like" there, it
fails, already having non-writable .prototype).
would you want to (otherwise, plain object is created for you).
What use-case?
Green pastures.
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.
This is innovation beyond any cowpath or stable strawman we've promoted
to Harmony in time for ES6. It goes beyond what we need, which Kevin
pointed out succinctly: per-class @@call specialization.
This "static" syntax was an example of what can follow.
It was kind-of a carrot. Showing that you can do this separation very
cleanly, if you have the class and constructor separated.
What I care for now, is the first step - opening the gates for
[[Construct]] and decoupling it from need of [[Call]]able function.
Or at least the first half-step: the fixed [[Construct]] semantics, that
fixes "super doesn't run the same initialization code as new SuperClass
would", and paving the way to, possibly, [[Construct]] on different objects.
/be
Herby
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
