On Dec 5, 2012, at 5:45 AM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
super(...) is just shorthand for super.constructor(...) (when it
occurs in a constructor) so it is just a use of [[Call]]. No magic.
[[Call]]/[[Init]] aside.
After reading the spec, it is really so that
Allen Wirfs-Brock wrote:
On Dec 5, 2012, at 5:45 AM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
super(...) is just shorthand for super.constructor(...) (when it
occurs in a constructor) so it is just a use of [[Call]]. No magic.
[[Call]]/[[Init]] aside.
It is bad for two reasons:
This
Herby Vojčík wrote:
__proto__s (the ones I mentioned above). You say that when they are
changed / out-of-sync / in whatever-else-nonstandard situation, then the
authoritative source of super-constructor for the SubClass constructor
should be SubClass.prototype.__proto__.constructor (that is,
Herby Vojčík wrote:
Herby Vojčík wrote:
__proto__s (the ones I mentioned above). You say that when they are
changed / out-of-sync / in whatever-else-nonstandard situation, then the
authoritative source of super-constructor for the SubClass constructor
should be
Allen Wirfs-Brock wrote:
super(...) is just shorthand for super.constructor(...) (when it
occurs in a constructor) so it is just a use of [[Call]]. No magic.
[[Call]]/[[Init]] aside.
After reading the spec, it is really so that super(...) in constructor
is in fact super.constructor(...),
Allen Wirfs-Brock wrote:
On Dec 3, 2012, at 3:03 PM, Jason Orendorff wrote:
On Sat, Dec 1, 2012 at 2:38 PM, Allen Wirfs-Brock
al...@wirfs-brock.com mailto:al...@wirfs-brock.com wrote:
The simplification I've thought about is eliminating [[Construct]]
as an internal method/Proxy
On Mon, Dec 3, 2012 at 6:52 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
OK, so it sounds like we have a plan. I'll update the spec. to use
@@create.
Thanks for resolving this. Having the class side inheritance for @@create
makes complete sense to me and it solves a lot of issues. It
Is there a missing step in that outlined algorithm? Where is [[Prototype]]
set?
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
@@create
2.5) Call
On Dec 4, 2012, at 5:37 AM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
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 @@create
3) Let
On Dec 4, 2012, at 7:21 AM, Erik Arvidsson wrote:
Is there a missing step in that outlined algorithm? Where is [[Prototype]]
set?
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
Allen Wirfs-Brock wrote:
On Dec 4, 2012, at 5:37 AM, Herby Vojčík wrote:
Allen Wirfs-Brock wrote:
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
On Tue, Dec 4, 2012 at 12:42 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
If you forget to do the super[create] call you don't get [[Prototype]]
initialized. However, if you leave out that super call you will also not
allocate any superclass provided per instance state. So, it would
On Dec 4, 2012, at 10:57 AM, Erik Arvidsson wrote:
On Tue, Dec 4, 2012 at 12:42 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
If you forget to do the super[create] call you don't get [[Prototype]]
initialized. However, if you leave out that super call you will also not
On Sat, Dec 1, 2012 at 2:38 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
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
On Dec 3, 2012, at 3:03 PM, Jason Orendorff wrote:
On Sat, Dec 1, 2012 at 2:38 PM, Allen Wirfs-Brock al...@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
Allen Wirfs-Brock wrote:
On Nov 30, 2012, at 2:20 PM, Jason Orendorff wrote:
The ordinary [[Construct]] internal method (which is what the new
operator actually uses) when invoked upon a constructor function
performs two steps. It first instantiates a new object instances (and
sets its
On Fri, Nov 30, 2012 at 7:40 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Overall, I like this approach. However, I don't think @@create belongs on
the prototype object. This make the @@create functionality for a
particular kind of object available to anyone who gets their hands on an
On Dec 1, 2012, at 10:40 AM, Jason Orendorff wrote:
On Fri, Nov 30, 2012 at 7:40 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
Overall, I like this approach. However, I don't think @@create belongs on the
prototype object. This make the @@create functionality for a particular kind
On Tue, Nov 27, 2012 at 12:40 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
On Nov 27, 2012, at 5:07 AM, David Bruant wrote:
WeakMap.call(o);
WeakSet.call(o);
Map.call(o);
Set.call(o);
Currently, this works and makes o a weakmap, a weakset, a map and a
set...
Sort
On Nov 30, 2012, at 2:20 PM, Jason Orendorff wrote:
On Tue, Nov 27, 2012 at 12:40 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Nov 27, 2012, at 5:07 AM, David Bruant wrote:
WeakMap.call(o);
WeakSet.call(o);
Map.call(o);
Set.call(o);
Currently, this works and
Hi,
var o = {};
WeakMap.call(o);
WeakSet.call(o);
Map.call(o);
Set.call(o);
Currently, this works and makes o a weakmap, a weakset, a map and a set...
I understand collections were spec'ed to enable subclassing, but I don't
see the value of being able to subclass this way
Le 27/11/2012 14:02, David Bruant a écrit :
Hi,
var o = {};
WeakMap.call(o);
WeakSet.call(o);
Map.call(o);
Set.call(o);
Currently, this works and makes o a weakmap, a weakset, a map and a
set...
I understand collections were spec'ed to enable subclassing, but I
don't see
On Nov 27, 2012, at 5:07 AM, David Bruant wrote:
Le 27/11/2012 14:02, David Bruant a écrit :
Hi,
var o = {};
WeakMap.call(o);
WeakSet.call(o);
Map.call(o);
Set.call(o);
Currently, this works and makes o a weakmap, a weakset, a map and a set...
Sort of. They won't
23 matches
Mail list logo
