Good-bye constructor functions?
allen at wirfs-brock.com
Tue Jan 8 10:00:55 PST 2013
On Jan 8, 2013, at 12:45 AM, Herby Vojčík wrote:
> Allen Wirfs-Brock wrote:
>> On Jan 7, 2013, at 4:09 PM, Herby Vojčík wrote:
>> I just don't see such an inconsistency in the current ES6 spec. draft. A
>> constructor is just a function that is usually called with a this value.
>> This is true whether it is called by the [[Constructor]] internal method
>> or via a super/super.constructor call. In either case, the primary
>> purpose of the constructor is to perform initialization actions upon the
>> this value. Where is the inconsistency?
> (I claim that) in any circumstances, what developers want to express when writing `super(...args)` in the constructoro of SubFoo, is:
> "On my this, which is now instance of SubFoo, I want the identical initialization code to be run, which `new Foo(...args)` would run to initialize newly created instance of Foo"
> That's not true. Because the spec is trying to serve two masters: F and F.prototype.constructor. It is impossible.
> The fixed semantics of [[Construct]] for `class` ((1) above) is fixing this by only serving one master: F.prototype.constructor (in line 3).
I agree with your above statement about initialization. But I also content that is exactly what the current specification of super does within a constructor function (subject, of course to what the invoked methods actually are coded to do). What I don't see is why you think otherwise. I need a clearer concrete explanation of what you see is the problem, prefably without a forward reference to what you think is the solution.
>> The only anomaly I see is that a handful of legacy built-ins do
>> completely different things for new operator originated calls in
>> contrast to regular function calls. There is no confusion in the spec.
>> about this and the mechanism for accomplishing it. However such split
>> behavior can't be declaratively defined in a normal function or class
>> declaration. In the other thread at
>> https://mail.mozilla.org/pipermail/es-discuss/2013-January/027864.html I
>> described how this split behavior an be procedurally described in such
>> declarations and also described how the same technique can be applied to
>> the offending built-in constructors (r any user defined class
>> constructor) to discriminate between initialization and "called"
>> behavior, even when called via super.
> Yes, but it is a workaround.
Or, alternatively stated, it shows how the objective can be met without any further complicating the actual language. That is arguably a good thing, not just a "woprkaround"
>> The only "fix" I saw that you made to super was that in you sketch
>> constructor methods defined via a class definition are only used for
>> instance initialization, so there doesn't need to be any code to
>> determine between initialization and call behavior. Constructor behavior
>> is always initialization behavior.
> Yes, it is there. As a free bonus, btw. The main druver for the design was new/super two masters fixing. Then, later (Brendan Eich will not like this ;-) ) the beauty of breaking the tight coupling and not needing [[Call]] at all for object with [[Construct]].
> There are in fact TWO freebies:
> - [[Call]] separated from [[Construct]]
> - you get default constructor for free; by not defining it explicitly.
Sorry, I still don't see it, you have to explain both the problem and your solution more concretely.
> When such freebies appear, for me this is the signal that someth8ing "clicks", eg., the design matches requirements very good.
>> However, you don't support non-new invocation behavior, at all, on class
>> objects so you can't use a class to self-host an implementation of, for
>> example, RegExp. You also, don't do any thing to support correct
> Read the rest of the reply, please. The exact contrary is in fact true. I do.
> (meta question: why it is so often here that people are cutting the rest and reply only on the first line dismissing the rest?)
> The proposal was first step: do class as plain objrct with [[Construct]], thereby blessing class/constructor separation.
> The second step is: when plain object can do, anything can do (the only question is how to specify it).
> It was sketched with more examples in the rest.
I did read the rest. I don't see any provisions for calling the class object. Can you point me concretely to where you define it?
More information about the es-discuss