2013/9/21 Allen Wirfs-Brock al...@wirfs-brock.com
On Sep 21, 2013, at 2:51 AM, Tom Van Cutsem wrote:
2013/9/20 Allen Wirfs-Brock al...@wirfs-brock.com
BTW, I would want to use [[InvokeFunction]] for both directly
obj.method() and in the internals of F.p.call/apply
As I mentioned to
2013/9/21 Allen Wirfs-Brock al...@wirfs-brock.com
On Sep 21, 2013, at 2:53 AM, Tom Van Cutsem wrote:
2013/9/21 Allen Wirfs-Brock al...@wirfs-brock.com
On Sep 20, 2013, at 5:31 PM, Brendan Eich wrote:
Given this, having the legacy internal calls continue to use get+call
seems fine to
2013/9/22 Jason Orendorff jason.orendo...@gmail.com
On Fri, Sep 20, 2013 at 6:27 PM, Brandon Benvie bben...@mozilla.com
wrote:
Actually, taking the precedent of removing getPropertyDescriptor, it's
has that would be removed.
I think the logic of the current design is: primitives we keep;
Has the specification licensing issue been discussed at the last TC39
conference yet? What is the results?
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
On Mon, Sep 23, 2013 at 10:33 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
Indeed, there are trade-offs and there is no silver bullet.
The status-quo, which I advocated, entails:
- we keep the invoke() trap, with its current signature: invoke(target,
propertyName, argsArray, receiver)
-
On Mon, Sep 23, 2013 at 3:40 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
To me hasOwn() is as much a primitive as e.g. Object.keys().
The only odd thing about it is that it lives on Object.prototype rather than
as a static method on Object.
I don't see the inconsistency, unless you would
On Sep 23, 2013, at 1:29 AM, Tom Van Cutsem wrote:
2013/9/21 Allen Wirfs-Brock al...@wirfs-brock.com
...
More concretely, existing code expects that
obj.valueOf()
is equivalent to
obj.valueOf.call()
but if obj is a transparent forwarding proxy on a map instance (or most
On Sep 23, 2013, at 1:33 AM, Tom Van Cutsem wrote:
2013/9/21 Allen Wirfs-Brock al...@wirfs-brock.com
...
c) double-lifting needs 2 traps (get + invoke) rather than just get.
I don't think so, using [[invokeFunction]] instead of [[Invoke]] eliminates
the need for two:
the current
Allen Wirfs-Brock wrote:
I'm actually more concerned about inconsistent behavior for both
internal (eg, valueOf) and user coded conditional calls.
Why? Lots of traps have to be implemented consistently, why is any
invoke used for explicit method calls, but get+call for implicit
conversions
Till Schneidereit wrote:
The issue triggering this entire thread is that some spec algorithms
don't use [[Invoke]], so the .invoke trap isn't triggered for them.
I'm now convinced that seeing that as an issue is ascribing too much
power to the .invoke trap. Let's state its behavior this way:
var obj = {};
Object.defineProperty(this, 'foo', obj.value = 0);
Object.defineProperty(this, 'foo2', obj.value = 1);
vs.
Object.defineProperty(this, 'foo', {value:0});
Object.defineProperty(this, 'foo2', {value:1});
Would the former method help with reducing object allocation (and therefore
*Would the former method help with reducing object allocation (and
therefore gc), or are there compiler optimizations that will automatically
make the latter as efficient?
On Mon, Sep 23, 2013 at 4:28 PM, J B por...@gmail.com wrote:
var obj = {};
Object.defineProperty(this, 'foo', obj.value
*oops:
obj.value = 0;
Object.defineProperty(this, 'foo', obj);
obj.value = 1;
Object.defineProperty(this, 'foo2', obj);
On Mon, Sep 23, 2013 at 4:30 PM, J B por...@gmail.com wrote:
*Would the former method help with reducing object allocation (and
therefore gc), or are there compiler
I wouldn't worry about object literal allocations for such (typically
one-time, up front) Object.defineProperty calls.
Also, es-discuss is not really the place to ask about how to write this
code.
/be
J B mailto:por...@gmail.com
September 23, 2013 2:40 PM
*oops:
obj.value = 0;
On Sep 23, 2013, at 12:53 PM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I'm actually more concerned about inconsistent behavior for both internal
(eg, valueOf) and user coded conditional calls.
Why? Lots of traps have to be implemented consistently, why is any invoke
used for
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
September 23, 2013 3:06 PM
It's a matter of internal vs external consistency. The implementor of
a Proxy handler needs to internally consistently implement the 'get',
'set', 'has', 'invoke', etc. traps in order to manifest an object that
exhibits
If I might, and sinve I've been using this or that for a while, I rather
find it convenient to use .value when you have other properties too instead
of writing them all the time.
That being said, for few shots ain't such big GC issue and actually some
engine is faster in doing this {value:value}
On Sep 23, 2013, at 3:50 PM, Brendan Eich wrote:
Allen Wirfs-Brock mailto:al...@wirfs-brock.com
September 23, 2013 3:06 PM
It's a matter of internal vs external consistency. The implementor of a
Proxy handler needs to internally consistently implement the 'get', 'set',
'has', 'invoke',
Hi Allen,
Your line of thinking has convinced me that `invoke` as it currently stands
doesn't really fly. However, I have an issue with your proposal. Take
this fragment:
(1) function f() { doSomethingWith(this); }
(2) f.call(obj);
Presently, the expression at (2) grants the function
On Sep 23, 2013, at 6:14 PM, Kevin Smith wrote:
Hi Allen,
Your line of thinking has convinced me that `invoke` as it currently stands
doesn't really fly. However, I have an issue with your proposal. Take this
fragment:
(1) function f() { doSomethingWith(this); }
(2)
On Sep 23, 2013, at 6:32 PM, Allen Wirfs-Brock wrote:
On Sep 23, 2013, at 6:14 PM, Kevin Smith wrote:
Hi Allen,
Your line of thinking has convinced me that `invoke` as it currently stands
doesn't really fly. However, I have an issue with your proposal. Take this
fragment:
What does f's handler refer to? If obj is a proxy and f is not, then obj
has a proxy and f does not.
On Mon, Sep 23, 2013 at 6:32 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Sep 23, 2013, at 6:14 PM, Kevin Smith wrote:
Hi Allen,
Your line of thinking has convinced me that
Sorry, I meant obj's handler
Mark S. Miller erig...@google.com wrote:
What does f's handler refer to? If obj is a proxy and f is not, then obj has
a proxy and f does not.
On Mon, Sep 23, 2013 at 6:32 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
On Sep 23, 2013, at 6:14 PM, Kevin
Ok, I've only been skimming the thread but I obviously missed something
crucial. How would
f.call(obj)
cause obj's handler to be invoked at all, much less be given access to f?
And why?
On Mon, Sep 23, 2013 at 7:14 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
Sorry, I meant obj's
24 matches
Mail list logo
