To confirm what Allen already mentioned: I too concluded from the
discussion that we would remove [[Invoke]] from ES6.
It is one of a few items I would like to put on the agenda of the TC39
November meeting to get a definitive consensus (the other item being the
removal of the hasOwn() trap, for
2013/10/18 Till Schneidereit t...@tillschneidereit.net
I share this concern. Last time we discussed it, Brendan said that we
could implement it by falling back to .get if .invoke isn't
defined[1]. I'm not sure how well that fits into the rest of the Proxy
design, though.
It doesn't fit the
I can't remember the conclusion of the earlier thread on this topic.
The question was about how implicit method calls should interact with
proxies in places (like
[ToPrimitive](http://people.mozilla.org/~jorendorff/es6-draft.html#sec-toprimitive))
where the spec first checks that the desired
On Oct 18, 2013, at 8:24 AM, Jason Orendorff wrote:
I can't remember the conclusion of the earlier thread on this topic.
The question was about how implicit method calls should interact with
proxies in places (like
On 10/18/2013 11:01 AM, Allen Wirfs-Brock wrote:
What your question does help me be more decisive on: We should not be in a rush
to add an Invoke, InvokeFunction, or any new traps not needed for membranes,
and not subject to a long history of examination. Invoke at least, as a derived
trap,
On Fri, Oct 18, 2013 at 8:06 PM, Brandon Benvie bben...@mozilla.com wrote:
On 10/18/2013 11:01 AM, Allen Wirfs-Brock wrote:
What your question does help me be more decisive on: We should not be in a
rush to add an Invoke, InvokeFunction, or any new traps not needed for
membranes, and not
On Oct 18, 2013, at 11:06 AM, Brandon Benvie wrote:
On 10/18/2013 11:01 AM, Allen Wirfs-Brock wrote:
What your question does help me be more decisive on: We should not be in a
rush to add an Invoke, InvokeFunction, or any new traps not needed for
membranes, and not subject to a long
users calling |builtin.call(thing)| don't expect
|thing| to influence the result of the call (cf. the discussion in the
[[invoke]] thread
http://esdiscuss.org/topic/invoke-and-implicit-method-calls#content-115).
Answering MarkM's question of whether we can self-host such behavior, I
believe we can
Le 26/09/2013 14:44, Anne van Kesteren a écrit :
On Thu, Sep 26, 2013 at 12:22 AM, Brendan Eich bren...@mozilla.com wrote:
Boris Zbarsky wrote:
The web _does_ in general rely on being able to apply methods from some
built-in (including DOM) prototype in one realm to objects from another
realm.
On 9/26/13 5:16 AM, Tom Van Cutsem wrote:
I believe the crucial part of why this works is because the built-ins
can recognize trusted, cross-realm proxies, from arbitrary other proxies.
Yes, agreed.
Answering MarkM's question of whether we can self-host such behavior, I
believe we can:
On 9/26/13 10:45 AM, David Bruant wrote:
Formulated differently: does the web has requirements making such
process isolation impossible?
Unclear.
The web has a requirement that if I have a pointer to a cross-origin
window win then doing win.name will find child windows of it with
name=name.
Mark S. Miller mailto:erig...@google.com
September 26, 2013 8:55 AM
I think we need to distinguish two senses of process when we ask this
question:
a) address space separation in the implementation
b) concurrency
#b would be a breaking semantic change, so I'm going to write that off
here.
I recall that Allen and I had previously agreed that it would be cleanest
if each of the [[internal]] methods on Object would correspond 1-to-1 to a
trap in the Proxy API (and I believe this is the case for the current ES6
draft).
So my stance is that we should either remove both hasOwn() and
2013/9/24 Brandon Benvie bben...@mozilla.com
It seems unfortunate that we have to rely on a membrane for something as
simply as `new Proxy(new Date, {}).getDate()` to work. [[Invoke]] as
currently specced gets us somewhere at least.
You don't necessarily need a full membrane if you want that
2013/9/24 Brendan Eich bren...@mozilla.com
Brandon Benvie mailto:bben...@mozilla.com
September 24, 2013 11:44 AM
It seems unfortunate that we have to rely on a membrane for something as
simply as `new Proxy(new Date, {}).getDate()` to work. [[Invoke]] as
currently specced gets us somewhere
Le 25/09/2013 11:18, Tom Van Cutsem a écrit :
2013/9/24 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
I think this is a key point. Things like 'new Proxy(new Date,
{}).getDate()' just don't work as expected with direct proxies and
we have not been able to
Le 25/09/2013 12:01, David Bruant a écrit :
Le 25/09/2013 11:18, Tom Van Cutsem a écrit :
2013/9/24 Allen Wirfs-Brock al...@wirfs-brock.com
mailto:al...@wirfs-brock.com
I think this is a key point. Things like 'new Proxy(new Date,
{}).getDate()' just don't work as expected with
On Wed, Sep 25, 2013 at 10:58 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
2013/9/24 Brendan Eich bren...@mozilla.com
Brandon Benvie mailto:bben...@mozilla.com
September 24, 2013 11:44 AM
It seems unfortunate that we have to rely on a membrane for something as
simply as `new Proxy(new
2013/9/25 Till Schneidereit t...@tillschneidereit.net
Note that .invoke is not in that part, though: once proxies ship (in more
than one browser) with all method calls invoking the .get handler, that
ship has sailed. Suddenly not invoking the .get handler, anymore, will
break applications.
Why does Date need private state? AFAICT, it only needs uniquely named
state. Why not do what we've done for many other bits of internal state
that doesn't need to be private: just name it with a unique symbol? This
doesn't work for all internal state of course, but it does seem it would
work for
On Wed, Sep 25, 2013 at 3:31 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
2013/9/25 Till Schneidereit t...@tillschneidereit.net
Note that .invoke is not in that part, though: once proxies ship (in more
than one browser) with all method calls invoking the .get handler, that
ship has sailed.
On Wed, Sep 25, 2013 at 8:18 AM, Till Schneidereit
t...@tillschneidereit.net wrote:
Note that .invoke is not in that part, though: once proxies ship (in more
than one browser) with all method calls invoking the .get handler, that ship
has sailed. Suddenly not invoking the .get handler, anymore,
On 9/25/13 5:18 AM, Tom Van Cutsem wrote:
The auto-unwrapping doesn't break membranes, because membranes never
expose direct references to built-in functions (they only expose wrapper
functions, which can still do whatever interposition they want before
calling the actual built-in).
I'd like
On Wed, Sep 25, 2013 at 4:08 PM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Sep 25, 2013 at 8:18 AM, Till Schneidereit
t...@tillschneidereit.net wrote:
Note that .invoke is not in that part, though: once proxies ship (in more
than one browser) with all method calls invoking the .get
Le 25/09/2013 15:49, Mark S. Miller a écrit :
Why does Date need private state? AFAICT, it only needs uniquely named
state. Why not do what we've done for many other bits of internal
state that doesn't need to be private: just name it with a unique symbol?
yes (assuming unique symbols are a
On Sep 25, 2013, at 3:01 AM, David Bruant wrote:
Le 25/09/2013 11:18, Tom Van Cutsem a écrit :
2013/9/24 Allen Wirfs-Brock al...@wirfs-brock.com
I think this is a key point. Things like 'new Proxy(new Date,
{}).getDate()' just don't work as expected with direct proxies and we have
not
On Sep 25, 2013, at 6:49 AM, Mark S. Miller wrote:
Why does Date need private state? AFAICT, it only needs uniquely named state.
Why not do what we've done for many other bits of internal state that doesn't
need to be private: just name it with a unique symbol? This doesn't work for
all
On Sep 25, 2013, at 1:26 AM, Tom Van Cutsem wrote:
I recall that Allen and I had previously agreed that it would be cleanest if
each of the [[internal]] methods on Object would correspond 1-to-1 to a trap
in the Proxy API (and I believe this is the case for the current ES6 draft).
So my
Le 25/09/2013 17:59, Allen Wirfs-Brock a écrit :
On Sep 25, 2013, at 3:01 AM, David Bruant wrote:
I think it's important to have a generic solution to avoid having
magic (non-self-hostable) built-ins (but I don't have this solution).
I don't think there is one, based upon Direct Proxies.
On 25 September 2013 15:49, Mark S. Miller erig...@google.com wrote:
Why does Date need private state? AFAICT, it only needs uniquely named
state. Why not do what we've done for many other bits of internal state that
doesn't need to be private: just name it with a unique symbol? This doesn't
On Wed, Sep 25, 2013 at 7:13 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 9/25/13 5:18 AM, Tom Van Cutsem wrote:
The auto-unwrapping doesn't break membranes, because membranes never
expose direct references to built-in functions (they only expose wrapper
functions, which can still do
That's why I picked on Date. We need to distinguish formerly-internal
potentially-public state from genuinely private state. WeakMap is
(ironically) a great example of an abstraction whose internal state must
remain private.
On Wed, Sep 25, 2013 at 7:22 AM, David Bruant bruan...@gmail.com wrote:
On Wed, Sep 25, 2013 at 8:59 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
On Sep 25, 2013, at 3:01 AM, David Bruant wrote:
Le 25/09/2013 11:18, Tom Van Cutsem a écrit :
2013/9/24 Allen Wirfs-Brock al...@wirfs-brock.com
I think this is a key point. Things like 'new Proxy(new Date,
On 9/25/13 3:47 PM, Mark S. Miller wrote:
Hi Boris, I don't understand what you mean by in general. I think the
SpiderMonkey use of cross-realm membranes is a great use case for
membranes, and I don't understand why they need any special logic at all
-- beyond the logic expressed by their
Le 25/09/2013 22:00, Boris Zbarsky a écrit :
On 9/25/13 3:47 PM, Mark S. Miller wrote:
Hi Boris, I don't understand what you mean by in general. I think the
SpiderMonkey use of cross-realm membranes is a great use case for
membranes, and I don't understand why they need any special logic at all
Boris Zbarsky wrote:
The web _does_ in general rely on being able to apply methods from
some built-in (including DOM) prototype in one realm to objects from
another realm.
This goes back to the dawn of JS. You can set location on a reachable
frame or window, even if not same-origin.
2013/9/23 Allen Wirfs-Brock al...@wirfs-brock.com
On Sep 23, 2013, at 1:29 AM, Tom Van Cutsem wrote:
I'm willing to consider changing the behavior of ForwardingHandler.get to
auto-wrap functions and re-bind their this-value. I think you may be right
that for users subclassing
Short summary:
The current (rev18) [[Invoke]] design allows this code to work (use case A):
js```
var p = new Proxy(new Map, {});
// Map.prototype.get is not generic, requires proper Map instance
p.get(key);
```
But it does not allow to use (use case B):
js```
var p = new Proxy(new Map, {});
2013/9/24 Mark S. Miller erig...@google.com
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?
This is exactly the hazard I alluded to in earlier mails.
[forking from [[invoke]]-thread for clarity]
2013/9/23 Jason Orendorff jason.orendo...@gmail.com
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
Thanks to André and Tom, I think I now understand the problem. I think the
only solution lies in this comment from Tom:
On Tue, Sep 24, 2013 at 1:23 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
[...] The generic solution is membranes. Anything else needs
application-specific consideration.
A solution that works is better than one that doesn't. We always knew that
patterns of proxies short of membranes would have abstraction leakage. This
is one. What is wrong with the stance: Live with it or use membranes,
I think I agree with this stance. Does that imply that we should drop
I would have no objections to dropping it. For me, the Invoke trap is
merely another derived trap whose main use is to avoid allocations needed
when relying only on more fundamental traps. See
https://mail.mozilla.org/pipermail/es-discuss/2013-September/033501.html.
These extra allocations are
On Tue, Sep 24, 2013 at 4:49 PM, Mark S. Miller erig...@google.com wrote:
I would have no objections to dropping it. For me, the Invoke trap is
merely another derived trap whose main use is to avoid allocations needed
when relying only on more fundamental traps. See
On Tue, Sep 24, 2013 at 7:23 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
[forking from [[invoke]]-thread for clarity]
Thanks!
Allen: would the removal of the hasOwn() trap imply that we can drop the
[[HasOwnProperty]] internal method altogether?
I searched the spec. There are not very many
On Sep 24, 2013, at 8:13 AM, Jason Orendorff wrote:
On Tue, Sep 24, 2013 at 7:23 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
[forking from [[invoke]]-thread for clarity]
Thanks!
Allen: would the removal of the hasOwn() trap imply that we can drop the
[[HasOwnProperty]] internal method
The way I see it, `invoke` (as currently specified) introduces new,
slightly incompatible function-call semantics, and doesn't really solve the
problem of transparent forwarding to targets with private state. Better
off without.
{ Kevin }
___
On Sep 24, 2013, at 7:37 AM, Mark S. Miller wrote:
Thanks to André and Tom, I think I now understand the problem. I think the
only solution lies in this comment from Tom:
On Tue, Sep 24, 2013 at 1:23 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
[...] The generic solution is membranes.
I do not know and I do not know what to search on to find out. However, I
would guess it is used enough to be a real concern. We documented it at
http://wiki.ecmascript.org/doku.php?id=conventions:safe_meta_programming
for reasons that are not Caja specific. That page followed from Axel's
One bit of data: A google search on uncurryThis says it gives 21,500
results. We should expect that many uses of this and similar patterns do
not use it by this name, so this should be taken, in some sense[1], as a
lower bound indication of the breadth of interest in such patterns.
[1] Insert
On Sep 24, 2013, at 10:18 AM, Mark Miller wrote:
One bit of data: A google search on uncurryThis says it gives 21,500
results. We should expect that many uses of this and similar patterns do not
use it by this name, so this should be taken, in some sense[1], as a lower
bound indication of
On Sep 24, 2013, at 10:06 AM, Mark S. Miller wrote:
I do not know and I do not know what to search on to find out. However, I
would guess it is used enough to be a real concern. We documented it at
http://wiki.ecmascript.org/doku.php?id=conventions:safe_meta_programming
for reasons that
Based on all the great input (thanks to André for his summary, and Mark
for pointing out works always beats half-works/half-broken), and
talking to Allen 1:1, I'm back to status quo ante: we are better off
being conservative designers by deferring invoke.
If we need to trial it as a strawman
Brandon Benvie mailto:bben...@mozilla.com
September 24, 2013 11:44 AM
It seems unfortunate that we have to rely on a membrane for something
as simply as `new Proxy(new Date, {}).getDate()` to work. [[Invoke]]
as currently specced gets us somewhere at least.
Somewhere half-right and
On Tue, Sep 24, 2013 at 8:38 PM, Brendan Eich bren...@mozilla.com wrote:
Based on all the great input (thanks to André for his summary, and Mark
for pointing out works always beats half-works/half-broken), and
talking to Allen 1:1, I'm back to status quo ante: we are better off being
You will get some migration from __noSuchMethod__, I predict, among
hobbyists and fans willing to write SpiderMonkey-specific code (or who
wrote it in the past, possibly a while ago, and who want to keep it going).
/be
Till Schneidereit mailto:t...@tillschneidereit.net
September 24, 2013
Well, yes, but only if we commit to keeping it around. Which we'd probably
not want to do if .invoke is removed from the spec for good.
On Tue, Sep 24, 2013 at 8:54 PM, Brendan Eich bren...@mozilla.com wrote:
You will get some migration from __noSuchMethod__, I predict, among
hobbyists and
On 9/24/2013 11:38 AM, Brendan Eich wrote:
Based on all the great input (thanks to André for his summary, and
Mark for pointing out works always beats half-works/half-broken),
and talking to Allen 1:1, I'm back to status quo ante: we are better
off being conservative designers by deferring
On Sep 24, 2013, at 8:13 AM, Jason Orendorff wrote:
/ On Tue, Sep 24, 2013 at 7:23 AM, Tom Van Cutsem tomvc.be at gmail.com
https://mail.mozilla.org/listinfo/es-discuss wrote:
// [forking from [[invoke]]-thread for clarity]
//
// Thanks!
//
// Allen: would the removal of the hasOwn()
On Sep 24, 2013, at 11:50 AM, Brendan Eich wrote:
Brandon Benvie mailto:bben...@mozilla.com
September 24, 2013 11:44 AM
It seems unfortunate that we have to rely on a membrane for something as
simply as `new Proxy(new Date, {}).getDate()` to work. [[Invoke]] as
currently specced gets
I think this is a key point. Things like 'new Proxy(new Date,
{}).getDate()' just don't work as expected with direct proxies and we have
not been able to fix that while maintaining other important semantic
requirements. If JS programmer have an expectation that they can usefully
write such
On Sep 24, 2013, at 12:15 PM, André Bargull wrote:
On Sep 24, 2013, at 8:13 AM, Jason Orendorff wrote:
On Tue, Sep 24, 2013 at 7:23 AM, Tom Van Cutsem tomvc.be at gmail.com
wrote:
[forking from [[invoke]]-thread for clarity]
Thanks!
Allen: would the removal of the hasOwn()
Till Schneidereit wrote:
Well, yes, but only if we commit to keeping it around. Which we'd
probably not want to do if .invoke is removed from the spec for good.
It's hard to say for good -- we did ban namespaces a la ES4/AS3 from
Harmony, but sometimes we do better by deferring rather than
Allen Wirfs-Brock al...@wirfs-brock.com wrote:
On Sep 24, 2013, at 12:15 PM, André Bargull wrote:
On Tue, Sep 24, 2013 at 2:34 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
I pretty sure we discussed this before and decided we wanted to
keep [[HasOwnProperty]]. However, the only reason
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;
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:
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
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
I've been only loosely following this thread, but I think Allen's proposal
has merit. If I understand correctly, it is extremely simple: provide
proxies with a hook into [[Call]], based on the `this` value.
{ Kevin }
___
es-discuss mailing list
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 your reply at the time, I believe the latter would break
the expectations of existing code.
Code that uses
2013/9/21 Allen Wirfs-Brock al...@wirfs-brock.com
On Sep 20, 2013, at 4:27 PM, Brandon Benvie wrote:
On 9/20/2013 12:19 PM, Jason Orendorff wrote:
I think .hasOwn() should be removed.
Actually, taking the precedent of removing getPropertyDescriptor, it's
has that would be removed. The
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 me. A proxy implementing toString, e.g., can make it work
using these traps just as well as via get+invoke,
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 your reply at the time, I believe the latter would
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 me. A proxy implementing toString, e.g., can make
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;
high-level operations that correspond to everyday syntax
Le 19/09/2013 10:53, Tom Van Cutsem a écrit :
2013/9/18 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
... I just realized that in your examples, the private state is
stored in a weakmap which requires target identity. If I recall,
the original problem wasn't so much with
2013/9/20 David Bruant bruan...@gmail.com
Further, a long-standing invariant in JS has been the equivalence of
o.m(...args) and m.call(o, ...args). The invoke trap allows allows to
break this invariant. I'm not sure this is for the best. This promotes a
given coding pattern, but at the
Well stated. Comments below.
Tom Van Cutsem mailto:tomvc...@gmail.com
September 20, 2013 12:02 PM
2013/9/20 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Further, a long-standing invariant in JS has been the equivalence
of o.m(...args) and m.call(o, ...args). The invoke
2013/9/20 Brendan Eich bren...@mozilla.com
Tom Van Cutsem mailto:tomvc...@gmail.com
And finally, if all we gain by leaving out invoke() is a simpler API,
then we should probably reconsider all derived traps. As I mentioned
earlier, we can easily get rid of traps like has(), hasOwn(), keys()
On Fri, Sep 20, 2013 at 8:50 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
To make matters more concrete, consider the has() trap:
foo in proxy // triggers has(target, foo), returns a boolean
Strictly speaking, we could do without the has() trap and instead call the
getOwnPropertyDescriptor()
2013/9/20 Jason Orendorff jason.orendo...@gmail.com
OK, taking all that at face value, what's the justification for .hasOwn()?
a) allows more direct interception of Object.prototype.hasOwnProperty()
b) potentially less allocations each time someone calls .hasOwnProperty().
I think .hasOwn()
I think the problem is not the existence of the invoke trap but the advice
we've talked about for using it. And I think this lesson applies to all
derived traps.
To maintain consistency, we should always advise overriding fundamental
traps first, and then consistent behavior for derived traps
On Sep 20, 2013, at 4:20 AM, Brendan Eich wrote:
...
But this makes proxies for special purpopes strictly harder to write, even
with a base handler implementation. Please correct me if I'm mistaken.
So I think we are better off with get+invoke, but I'm still troubled by the
double
On Fri, Sep 20, 2013 at 1:17 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
2013/9/20 Jason Orendorff jason.orendo...@gmail.com
I think .hasOwn() should be removed.
I assume you're making the case to remove all derived traps then, not just
hasOwn()?
No, my question about the justification for
Still expected for ES7. Of course, you can use WeakMaps for private state
manually in ES6 in the meantime.
On Fri, Sep 20, 2013 at 2:33 PM, David Bruant bruan...@gmail.com wrote:
Le 20/09/2013 13:02, Tom Van Cutsem a écrit :
2013/9/20 David Bruant bruan...@gmail.com
I'm still inclined
Le 20/09/2013 13:02, Tom Van Cutsem a écrit :
2013/9/20 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
I'm still inclined to think a generic solution to private state
and proxies should be found. Given this solution, the invoke trap
may end up being plain redundant. That
1 - 100 of 173 matches
Mail list logo
