Allowing super to use EvaluateConstruct, or "How do I inherit from Date?"

Herby Vojčík herby at mailbox.sk
Mon Jan 7 13:43:54 PST 2013



Allen Wirfs-Brock wrote:
>
> I think the real issue is whether we want to encourage the style of
> constructor where "called as a constructor" and "called as a function"
> do completely different things. I'm leaning towards the conclusions that
> we shouldn't. One reason is that the language is fighting so hard
> against that pattern. Anything that requires multiple low level hacks to
> the language semantics (and possibly new syntax) to make it "just work"
> probably is something that shouldn't be done.

Well, I would disagree strongly.

The "problem" here stems from tightky coupling the constructor function 
to the "class". Those two things can be very cleanly and minimally 
sepaerated.

Read my "Good bye constructor functions?" post from Dec 30. This pattern 
(class = constructor) is very deeply grown into thinking of JS 
developer, but it is not the law. It is very easy to get rid of it.

Then, nothing from below is ever needed. It all follows naturally. Anf 
without hacks.

> For the non-spec readers out there, here is the jury rigging pattern.
> Every "class" in the spec. that has different constructor/function call
> behavior has (will have) a @@create method that allocates its instances
> and in the process tags the instance with a brand and perhaps a not yet
> initialized flag. In a new expression, the @@create call happens before
> the call to the actual constructor function and the result of the
> @@create call is what is passed as the this value to the constructor.
>
> The constructor function, itself, is defined to determine its behavior
> based upon the this value that is passed to it. It the this value is
> branded with the instance brand, the constructor initializes and returns
> the instance according to its normal definition. Otherwise, if the this
> value is not an object or an object without the instance brand then the
> constructor performs the "call" functionality.
>
> For the existing built-in this jury rig appears to be adequate for
> ensuring compatibility with all existing code. Consider all the ways
> that, for example, Number can currently be "called as a function":
>
> let n;
> n = Number("1234"); //this is undefined so jury rig takes ToNumber path
> within constructor.
> n = Number.call(null, "1") //this is null so jury rig takes ToNumber
> path within constructor.
> n = Number.call(1, "1") //this is not an object so jury rig takes
> ToNumber path within constructor.
> n = Number.call(new Object, "1"); //this is an object without the number
> brand so jury rig takes ToNumber path within constructor.
> n = {foo: Number}.foo("1"); //this is an object without the number brand
> so jury rig takes ToNumber path within constructor.
> n = Number.call(new Number("2"), "1"); //this is an object with the
> number brand but it is already initialized so (for backwards compat)
> jury rig takes ToNumber path within constructor.
> Number.prototype.bar = Number;
> n=new Number(2).bar("1"; //this is an object with the number brand but
> it is already initialized so jury rig takes ToNumber path within
> constructor.
>
> But in ES6 (now backwards compat issues here):
> class MyNumber extends Number {
> additionalNumberMethod () {}
> }
>
> n = new MyNumber("1"); //default constructor does super.constructor call
> with new instance created by Number.@@create, so initialization path
> taken with Number.
>
> n = MyNumber("1") //default constructor does super.constructor call with
> undefined as this value, so ToNumber path taken and Number(1) is returned.
> But if MyNumber wants to also expose its own explicit conversions
> behavior it will need to provide its own constructor that decides when
> to take that path
>
> Here is a ES level example, of defining a class that uses the "called
> same as new" pattern:
>
> const $myBrand = new Symbol(true);
> import $create ...;
>
> class MyObj {
> constructor () {
> if (typeof this !== 'object' || this == null || !Reflect.has($myBrand))
> return new MyObj();
> /* could check here for this already initialized */
> /* do any initialization */
> this[$myBrand] = true; //tag as initialized
> }
> }
> Object.mixin(MyObj, {
> [$create] () {
> let obj = super(); //call default @@create
> Object.defineOwnProperty(obj,$myBrand,{value: undefined, writable: true});
> return obj;
> }
> });
>


More information about the es-discuss mailing list