On Jan 7, 2013, at 8:46 AM, Brandon Benvie wrote:
> Also it's not just confusing. Arrays and Date can be jury rigged to function
> correctly with the recent ES6 spec changes, as you demonstrated. That still
> leaves it impossible to extend Boolean, Number, String, and RegExp (leaving
> out Function on purpose since that's in a league of its own and would depend
> on @@call being added) because they are construct sensitive and have no
> post-creation way of mutating their internal value.
They all can be jury rigged. At the level of the specification I can factor
the initialization between the @@create function and the built-in constructor
pretty much any way I want while still preserving external immutability of the
internal data properties. ES code can doing similar things via private symbols.
The patterns I use for this jury rigging work for both direct and super calls
to the constructors.
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.
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;
}
});
>
>
>
>
>
> On Mon, Jan 7, 2013 at 11:38 AM, Brandon Benvie <[email protected]>
> wrote:
> Yeah, that's a better way to say what I (poorly) expressed. It's not that
> EvaluateConstruct needs to again be called (this would cause multiple
> allocations). Rather, the super call that arose directly from
> EvaluateConstruct needs to pass its "constructness" onto the SuperConstructor.
>
>
> On Mon, Jan 7, 2013 at 11:35 AM, Erik Arvidsson <[email protected]>
> wrote:
> On Sun, Jan 6, 2013 at 10:32 PM, Brandon Benvie
> <[email protected]> wrote:
> > Despite separating out @@create into a property of functions, which allows
> > allocation and setting of BuiltinBrand for subclasses, this still leaves
> > inheriting from most builtins just short of possible because they are
> > "construct sensitive". The new ES6 classes like Map, Set, WeakMap, and typed
> > arrays have been carefully designed so the constructor initializes `this`.
> > But this still leaves most of the existing builtins un-subclassable.
>
> I think you are making this sound worse than it is.
>
> What isn't working is that super in the constructor doesn't do what you
> expect. The following should work
>
> class MyArray extends Array {
> constructor(...args) {
> // Intentionally not doing the crazy one-arg-is-length-if-uint32
> this.push(...args);
> }
> }
>
> class MyDate extends Date {
> constructor(..args) {
> var temp = new Date(...args);
> this.setTime(temp.getTime());
> }
> }
>
> I agree that it will be confusing to most users and that we should try
> to make super in a constructor work for these cases.
>
> --
> erik
>
>
> _______________________________________________
> es-discuss mailing list
> [email protected]
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
