Good-bye constructor functions?

Herby Vojčík herby at
Tue Jan 8 03:57:41 PST 2013

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 
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


More information about the es-discuss mailing list