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
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
33 matches
Mail list logo
