erik.arvidsson at gmail.com
Tue Dec 4 07:21:27 PST 2012
Is there a missing step in that outlined algorithm? Where is [[Prototype]]
So roughly speaking, Foo.[[Constructor]](...args) would be defined as:
1) Let creator be Foo.[[Get]](@@create)
2 ) Let newObj be creator.call(foo). //Foo is passed as the this value to
2.5) Call newObj.[[SetInheritance]](Foo.prototype)
3) Let ctorResult be Foo.[[call]](newObj,args)
4) If Type(ctorResult) is Object, return ctorResult
5) else return newObj
On Mon, Dec 3, 2012 at 6:52 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
> On Dec 3, 2012, at 3:03 PM, Jason Orendorff wrote:
> On Sat, Dec 1, 2012 at 2:38 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:
>> The simplification I've thought about is eliminating [[Construct]] as an
>> internal method/Proxy trap and just making the call @@Create/call
>> consturctor sequence the evaluation semantics of the new operator. But
>> I've not yet convinced myself that this is sufficient to capture all of the
>> "called as constructor"/"called as a function" semantic silliness that some
>> chapter 15 built-ins have. I'm also not sure that DOM and friends don't
>> have other dependencies on a reified [[Construt]]
> The simplification I had in mind was changing [[Construct]] from an
> internal method/Proxy trap to an ordinary .@@construct method. There would
> be a @@construct/constructor split rather than a
> [[Construct]]/@@create/constructor split.
> But on reflection, it didn't seem like that would be simpler in practice.
> Having two separately hookable phases of object construction is just right.
> A class can easily customize either behavior in a way that not only works,
> but will still work when the class is subclassed further.
> OK, so it sounds like we have a plan. I'll update the spec. to use
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss