To pick up this thread again, I gave a talk about the trade-offs in
designing JS proxies at a meeting last week. The people following this
thread may be interested in seeing the slides:
http://soft.vub.ac.be/~tvcutsem/invokedynamic/presentations/Tradeoffs_WGLD2012_Austin.pdf
(the talk
Le 03/12/2012 00:06, David Bruant a écrit :
The call to action performs
the original operation on target and remembers the result. After the
trap returns, the proxy returns the remembered result of action.
target = {a:1};
var p = new Proxy(target, {
get: function(target, name,
What eternal[1] invariant does this bypass?
[1] https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html
On Mon, Dec 3, 2012 at 3:33 AM, David Bruant bruan...@gmail.com wrote:
Le 03/12/2012 00:06, David Bruant a écrit :
The call to action performs
the original operation on target
Le 03/12/2012 16:38, Mark S. Miller a écrit :
What eternal[1] invariant does this bypass?
[1] https://mail.mozilla.org/pipermail/es-discuss/2011-May/014150.html
Apparently none... Yet, additionally to the last case I showed, there is
also:
var p = new Proxy({a:1}, {
isExtensible:
2012/11/28 Brandon Benvie bran...@brandonbenvie.com
Object.observe would fit under after correct?
Yes, with two remarks:
- it only traps updating operations
- the traps are called in a separate turn (i.e. asynchronously), so they
cannot change the result of the operation
Cheers,
Tom
2012/11/28 David Bruant bruan...@gmail.com
I don't understand why a unique token per trap invocation would be
necessary.
I still don't understand this point.
I've gone spelunking. I've found:
* the wiki page [1] (reflecting July meeting) which mentions that
returning undefined would
2012/11/29 Dean Tribble dtrib...@gmail.com
As a general point, I encourage you to look for other inspiration than
CLOS MOP for doign proxies (whose mother was really InterlispD). Meta-level
access deeply impacts security,maintainability,
reliability, understandability, etc. The tighter and
Le 02/12/2012 17:27, Tom Van Cutsem a écrit :
2012/11/28 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
I don't understand why a unique token per trap invocation would
be necessary.
I still don't understand this point.
I've gone spelunking. I've found:
* the
Le 02/12/2012 17:43, David Bruant a écrit :
Maybe I'm too influenced by the JVM, but my understanding is that
wrapping every call to a trap with a try-catch block won't be free.
The more interesting question is whether it would be significantly
cheaper than 'returning a value+invariant checks'
On Sun, Dec 2, 2012 at 8:40 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
- after-style wrapping allows you to get notified of an operation
after-the-fact. Depending on the API, the after-wrapper may or may not get
to see the outcome of the operation, and may or may not change the final
outcome
2012/12/2 Mark S. Miller erig...@google.com
I think we can rescue around wrapping. I'll call this approach opaque
around wrapping. The idea is that the proxy passes into the handler
trap a proxy-generated no-argument function (a thunk) called action.
Interesting. I had thought of a similar
On Dec 2, 2012, at 11:40 AM, Tom Van Cutsem wrote:
2012/12/2 Mark S. Miller erig...@google.com
I think we can rescue around wrapping. I'll call this approach opaque
around wrapping. The idea is that the proxy passes into the handler
trap a proxy-generated no-argument function (a thunk)
Le 02/12/2012 18:34, Mark S. Miller a écrit :
On Sun, Dec 2, 2012 at 8:40 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
- after-style wrapping allows you to get notified of an operation
after-the-fact. Depending on the API, the after-wrapper may or may not get
to see the outcome of the
Le 02/12/2012 20:40, Tom Van Cutsem a écrit :
2012/12/2 Mark S. Miller erig...@google.com mailto:erig...@google.com
I think we can rescue around wrapping. I'll call this approach opaque
around wrapping. The idea is that the proxy passes into the handler
trap a proxy-generated
2012/11/26 Dean Tribble dtrib...@gmail.com
On Mon, Nov 26, 2012 at 11:33 AM, Tom Van Cutsem tomvc...@gmail.comwrote:
Thanks for spelling out these examples. While they still don't feel like
actual important use cases to support, they give a good flavor of the kinds
of compromises we'd need
Object.observe would fit under after correct?
On Wed, Nov 28, 2012 at 4:09 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
2012/11/26 Dean Tribble dtrib...@gmail.com
On Mon, Nov 26, 2012 at 11:33 AM, Tom Van Cutsem tomvc...@gmail.comwrote:
Thanks for spelling out these examples. While they
Le 26/11/2012 21:39, David Bruant a écrit :
Le 26/11/2012 20:59, Tom Van Cutsem a écrit :
2012/11/26 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
We could define a symbolic value (like StopIteration for
iterators) that would mean forward to target. By essence of
what
On Wed, Nov 28, 2012 at 1:09 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
2012/11/26 Dean Tribble dtrib...@gmail.com
...
I agree. My usual expectation for proxies is to support remote and
persistent objects. While supporting other scenarios is great, usually
that's incidental. Is there a
On Nov 28, 2012, at 1:09 PM, Tom Van Cutsem wrote:
2012/11/26 Dean Tribble dtrib...@gmail.com
On Mon, Nov 26, 2012 at 11:33 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
Thanks for spelling out these examples. While they still don't feel like
actual important use cases to support, they give
Le 25/11/2012 15:32, Axel Rauschmayer a écrit :
If indeed both kinds of proxy are useful and direct proxies are more
powerful, then why not only have a foundational direct proxy API and
implement a tool type NotificationProxy that is based on that API.
An interesting question I still haven't
Le 25/11/2012 12:44, Tom Van Cutsem a écrit :
(...)
I agree that the big benefit of notification proxies is that they get
rid of all the complex validation logic.
However, some reservations:
(...)
- I think we do lose some expressiveness in the case of pure virtual
object abstractions that
On Mon, Nov 26, 2012 at 3:36 AM, David Bruant bruan...@gmail.com wrote:
Le 25/11/2012 15:32, Axel Rauschmayer a écrit :
If indeed both kinds of proxy are useful and direct proxies are more
powerful, then why not only have a foundational direct proxy API and
implement a tool type
On Nov 26, 2012, at 12:36 AM, David Bruant wrote:
Le 25/11/2012 15:32, Axel Rauschmayer a écrit :
If indeed both kinds of proxy are useful and direct proxies are more
powerful, then why not only have a foundational direct proxy API and
implement a tool type NotificationProxy that is based
Le 26/11/2012 19:58, Allen Wirfs-Brock a écrit :
On Nov 26, 2012, at 12:36 AM, David Bruant wrote:
Le 25/11/2012 15:32, Axel Rauschmayer a écrit :
If indeed both kinds of proxy are useful and direct proxies are more
powerful, then why not only have a foundational direct proxy API and
2012/11/25 Allen Wirfs-Brock al...@wirfs-brock.com
I have a couple virtual object use cases in mind where I don't think I
would want to make all properties concrete on the target.
Thanks for spelling out these examples. While they still don't feel like
actual important use cases to support,
There's a few goals I have in mind when thinking about proxies:
* Ability to forward to target at minimal cost.
* Minimal cost for invariant enforcement, preferably automatic since the
result is predetermined
* Near zero cost for invariant enforcement in the majority of cases where
it's not needed
I started to respond to Allan's message, but I'll combine them to here.
Note the additional proposal in the middle of the message.
On Mon, Nov 26, 2012 at 11:33 AM, Tom Van Cutsem tomvc...@gmail.com wrote:
2012/11/25 Allen Wirfs-Brock al...@wirfs-brock.com
I have a couple virtual object use
Le 26/11/2012 20:59, Tom Van Cutsem a écrit :
2012/11/26 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
We could define a symbolic value (like StopIteration for
iterators) that would mean forward to target. By essence of what
forwarding to the target means, there would be
Hi,
I will refer to Dean's proposal as notification proxies (where traps
essentially become notification callbacks), and will continue to use
direct proxies for the current design where the trap can return a result
(which is then verified).
These notification proxies remind me a lot of how one
I think it could be argued that the two categories of proxy uses have
different enough fundamentals that they would be better suited broken into
two separate types of proxies. They use a common protocol for dispatching
notifications/requests, but the result is incompatible.
For a Notification
If indeed both kinds of proxy are useful and direct proxies are more powerful,
then why not only have a foundational direct proxy API and implement a tool
type NotificationProxy that is based on that API.
[[[Sent from a mobile device. Please forgive brevity and typos.]]]
Dr. Axel Rauschmayer
On Nov 25, 2012, at 4:15 AM, Brandon Benvie wrote:
I think it could be argued that the two categories of proxy uses have
different enough fundamentals that they would be better suited broken into
two separate types of proxies. They use a common protocol for dispatching
On Nov 25, 2012, at 3:44 AM, Tom Van Cutsem wrote:
Hi,
I will refer to Dean's proposal as notification proxies (where traps
essentially become notification callbacks), and will continue to use direct
proxies for the current design where the trap can return a result (which is
then
On Nov 25, 2012, at 6:32 AM, Axel Rauschmayer wrote:
If indeed both kinds of proxy are useful and direct proxies are more
powerful, then why not only have a foundational direct proxy API and
implement a tool type NotificationProxy that is based on that API.
That might work. In that case
...@mozilla.com
Subject: possible excessive proxy invariants for Object.keys/etc??
I'm wondering if the wiki spec. for these functions aren't doing
invariant checking that goes beyond what is required for the integrity
purposes you have stated.
In general, proxies traps check to ensure
Orendorff jorendo...@mozilla.com
Subject: possible excessive proxy invariants for Object.keys/etc??
I'm wondering if the wiki spec. for these functions aren't doing
invariant checking that goes beyond what is required for the integrity
purposes you have stated.
In general, proxies traps
2012/11/21 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 21, 2012, at 12:09 PM, Tom Van Cutsem wrote:
Let's first discuss whether there is an issue with just letting (unique)
symbols show up in Object.{keys,getOwnPropertyNames}.
It's still a change in return type (from Array[String] to
On Nov 22, 2012, at 5:36 AM, Tom Van Cutsem wrote:
2012/11/21 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 21, 2012, at 12:09 PM, Tom Van Cutsem wrote:
Let's first discuss whether there is an issue with just letting (unique)
symbols show up in Object.{keys,getOwnPropertyNames}.
It's
Le 21/11/2012 01:06, Allen Wirfs-Brock a écrit :
b) that all the elements of the result are Strings
And presumably Symbols. We have to also accommodate Symbols, at
least for getOwnPropetyNames. Regardless, why is this
important? More below...
Same argument as above.
I
On 21 November 2012 01:06, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Tom Van Cutsem tomvc...@gmail.com wrote:
Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Tom Van Cutsem tomvc...@gmail.com wrote:
c) to ensure the stability of the result.
You can think of a + b as implementing a type
On Nov 21, 2012, at 1:55 AM, David Bruant wrote:
Le 21/11/2012 01:06, Allen Wirfs-Brock a écrit :
b) that all the elements of the result are Strings
And presumably Symbols. We have to also accommodate Symbols, at least for
getOwnPropetyNames. Regardless, why is this important? More
On Nov 21, 2012, at 3:54 AM, Andreas Rossberg wrote:
On 21 November 2012 01:06, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Tom Van Cutsem tomvc...@gmail.com wrote:
Allen Wirfs-Brock al...@wirfs-brock.com wrote:
Tom Van Cutsem tomvc...@gmail.com wrote:
c) to ensure the stability of the
On 21 November 2012 17:55, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
I'd be more favorably inclined towards freezing than I am towards copying.
But, as you know, ES5 does not currently produce frozen objects in these
situations. I feel uncomfortable about enforcing a frozen invariant
On 21 November 2012 18:35, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
If you are writing any sort of generic algorithm that does a freeze check on
an arbitrary object you have to explicitly perform all of the internal method
calls because you don't know whether the object is a proxy
Le 21/11/2012 17:37, Allen Wirfs-Brock a écrit :
On Nov 21, 2012, at 1:55 AM, David Bruant wrote:
Le 21/11/2012 01:06, Allen Wirfs-Brock a écrit :
b) that all the elements of the result are Strings
And presumably Symbols. We have to also accommodate Symbols,
at least for
2012/11/19 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 19, 2012, at 10:04 AM, Tom Van Cutsem wrote:
It's all a matter of developer expectations and how much leeway we have in
changing the return type of existing built-ins.
In theory, it's a backwards-incompatible change. In practice,
2012/11/21 David Bruant bruan...@gmail.com
Since the use of Object.getOwnPropertyNames may not be widespread, maybe
that making non-enumerable unique symbol properties could do the trick (as
it has with new {Object, Array, etc.}.prototype additions)
1bis) If all standard built-in names are
2012/11/21 Allen Wirfs-Brock al...@wirfs-brock.com
I'd be more favorably inclined towards freezing than I am towards copying.
But, as you know, ES5 does not currently produce frozen objects in these
situations. I feel uncomfortable about enforcing a frozen invariant for
traps where that
2012/11/21 Mark S. Miller erig...@google.com
On Wed, Nov 21, 2012 at 8:55 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
[...] Essentially we could internally turn the [[Extensible]] internal
property into a four state value: open,non-extensible,sealed,frozen. [...]
First, my
On Nov 21, 2012, at 11:13 AM, David Bruant wrote:
Le 21/11/2012 17:37, Allen Wirfs-Brock a écrit :
On Nov 21, 2012, at 1:55 AM, David Bruant wrote:
Le 21/11/2012 01:06, Allen Wirfs-Brock a écrit :
b) that all the elements of the result are Strings
And presumably Symbols. We have to
On Wed, Nov 21, 2012 at 12:42 PM, Tom Van Cutsem tomvc...@gmail.com wrote:
2012/11/21 Mark S. Miller erig...@google.com
On Wed, Nov 21, 2012 at 8:55 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
[...] Essentially we could internally turn the [[Extensible]] internal
property into a
Le 21/11/2012 21:13, Tom Van Cutsem a écrit :
2012/11/21 David Bruant bruan...@gmail.com mailto:bruan...@gmail.com
Since the use of Object.getOwnPropertyNames may not be widespread,
maybe that making non-enumerable unique symbol properties could do
the trick (as it has with new
On Nov 21, 2012, at 12:09 PM, Tom Van Cutsem wrote:
2012/11/19 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 19, 2012, at 10:04 AM, Tom Van Cutsem wrote:
It's all a matter of developer expectations and how much leeway we have in
changing the return type of existing built-ins.
In theory,
On Nov 21, 2012, at 12:27 PM, Tom Van Cutsem wrote:
2012/11/21 Allen Wirfs-Brock al...@wirfs-brock.com
I'd be more favorably inclined towards freezing than I am towards copying.
But, as you know, ES5 does not currently produce frozen objects in these
situations. I feel uncomfortable
On Nov 21, 2012, at 12:42 PM, Tom Van Cutsem wrote:
2012/11/21 Mark S. Miller erig...@google.com
On Wed, Nov 21, 2012 at 8:55 AM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
[...] Essentially we could internally turn the [[Extensible]] internal
property into a four state value:
with other to
follow:
Begin forwarded message:
From: Allen Wirfs-Brock al...@wirfs-brock.com
Date: November 18, 2012 1:26:14 PM PST
To: Tom Van Cutsem tomvc...@gmail.com, Mark S. Miller erig...@google.com
Cc: Jason Orendorff jorendo...@mozilla.com
Subject: possible excessive proxy invariants
Hi Allen,
2012/11/18 Allen Wirfs-Brock al...@wirfs-brock.com
The proxy spec.for Object.getOwnPropertyNames/kets/etc. seem to be doing quite
a bit more than this. They
1) always copy the array returned from the trap? Why is this necessary? Sure
the author of a trap should probably always
On Nov 19, 2012, at 10:04 AM, Tom Van Cutsem wrote:
Hi Allen,
2012/11/18 Allen Wirfs-Brock al...@wirfs-brock.com
The proxy spec.for Object.getOwnPropertyNames/kets/etc. seem to be doing
quite a bit more than this. They
1) always copy the array returned from the trap? Why is this
2012/11/19 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 19, 2012, at 10:04 AM, Tom Van Cutsem wrote:
The copying is to ensure:
a) that the result is an Array
Why is Array-ness essential? It was what ES5 specified, but ES5 had a fixed
implementations of Object.getOwnPropertyNames/keys so
19, 2012 10:04:56 AM PST
To: Allen Wirfs-Brock al...@wirfs-brock.com
Cc: Mark S. Miller erig...@google.com, Jason Orendorff
jorendo...@mozilla.com
Subject: Re: possible excessive proxy invariants for Object.keys/etc??
Hi Allen,
2012/11/18 Allen Wirfs-Brock al...@wirfs-brock.com
Begin forwarded message:
From: Allen Wirfs-Brock al...@wirfs-brock.com
Date: November 19, 2012 2:11:52 PM PST
To: Tom Van Cutsem tomvc...@gmail.com
Cc: Mark S. Miller erig...@google.com, Jason Orendorff
jorendo...@mozilla.com
Subject: Re: possible excessive proxy invariants
Begin forwarded message:
From: Tom Van Cutsem tomvc...@gmail.com
Date: November 20, 2012 11:36:24 AM PST
To: Allen Wirfs-Brock al...@wirfs-brock.com
Cc: Mark S. Miller erig...@google.com, Jason Orendorff
jorendo...@mozilla.com
Subject: Re: possible excessive proxy invariants
In regards to the non-configurable/extensible issue, the issue is that the
proxy still needs to be *notified* of what's happening, but it's not really
allowed to *trap* because the result is predetermined. Currently this is
handled by treating it like a normal trap activation with extra
, Jason Orendorff
jorendo...@mozilla.com
Subject: Re: possible excessive proxy invariants for Object.keys/etc??
2012/11/19 Allen Wirfs-Brock al...@wirfs-brock.com
On Nov 19, 2012, at 10:04 AM, Tom Van Cutsem wrote:
The copying is to ensure:
a) that the result is an Array
Why is Array-ness
On Nov 20, 2012, at 3:16 PM, Brandon Benvie wrote:
In regards to the non-configurable/extensible issue, the issue is that the
proxy still needs to be *notified* of what's happening, but it's not really
allowed to *trap* because the result is predetermined. Currently this is
handled by
65 matches
Mail list logo
