Notification proxies (Was: possible excessive proxy invariants for Object.keys/etc??)

David Bruant bruant.d at gmail.com
Mon Nov 26 00:36:08 PST 2012


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 found a satisfying answer to is: 
is the additional power of current proxies useful? and worth the cost? 
Because the current freedom of proxies is the root cause of invariant 
checks that even good proxy citizens have to pay.

David
>
>
> [[[Sent from a mobile device. Please forgive brevity and typos.]]]
>
> Dr. Axel Rauschmayer
> axel at rauschma.de <mailto:axel at rauschma.de>
> Home: http://rauschma.de
> Blog: http://2ality.com
>
> On 25.11.2012, at 12:44, Tom Van Cutsem <tomvc.be at gmail.com 
> <mailto:tomvc.be at gmail.com>> 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 verified).
>>
>> These notification proxies remind me a lot of how one must implement 
>> membranes with direct proxies. The general idea here is that the 
>> proxy must use a "shadow" target as the proxy target, and the handler 
>> must refer to the "real" wrapped target. Traps that have to do with 
>> invariants (e.g. freeze/isFrozen, or querying a non-configurable 
>> property descriptor) require the proxy to "synchronize" the state of 
>> the real and shadow targets, because the proxy will verify the trap 
>> result against the shadow target.
>>
>> For such membranes, let's consider how direct proxies and 
>> notification proxies trap an operation:
>>
>> Direct proxies:
>> 1) the proxy calls a trap on the handler
>> 2) if the operation involves strong invariants on the real target, 
>> the handler must synchronize real and shadow target
>> 3) the trap returns a result
>> 4) if the proxy detects that the operation involves strong 
>> invariants, the trap result is verified against the shadow target
>>
>> Notification proxies:
>> 1) the proxy calls a trap on the handler (as a notification)
>> 2) the handler must synchronize real and shadow target (regardless of 
>> whether invariants are involved)
>> 3) the trap returns no result
>> 4) the proxy performs the intercepted operation on the shadow and 
>> returns the result
>>
>> I agree that the big benefit of notification proxies is that they get 
>> rid of all the complex validation logic.
>>
>> However, some reservations:
>>
>> - if traps become mere notifications, perhaps their names should 
>> change to reflect this, e.g. "notifyGetOwnPropertyNames" instead of 
>> "getOwnPropertyNames". This is to alert handler writers that the 
>> return value of these traps will be ignored.
>>
>> - I think we do lose some expressiveness in the case of pure virtual 
>> object abstractions that don't pretend to uphold any invariants.
>> With notification proxies, the handler must always (even in the case 
>> of configurable properties) define concrete properties on the target. 
>> Any virtual object abstraction is thus forced to maintain a "shadow" 
>> which must eventually be represented as a plain Javascript object.
>> In other words: *all* virtual object abstractions, whether they 
>> pretend to be frozen or not, have to make use of the "shadow target" 
>> technique, with the burden of synchronizing the shadow upon each 
>> operation. That burden currently doesn't exist for non-frozen virtual 
>> object abstractions (I'm using "frozen" vs "non-frozen" here as a 
>> shorthand for "has non-configurable/non-extensible invariants" vs 
>> "has no such invariants").
>>
>> - Regarding the overhead of the getOwnPropertyNames trap having to 
>> create a defensive copy of the trap result:
>> With notification proxies, upon trapping "notifyGetOwnPropertyNames":
>> 1) the trap must define all properties it wants to return on the 
>> target. If there are N properties, there is an O(N) physical storage 
>> cost involved.
>> 2) the proxy applies the built-in Object.getOwnPropertyNames to the 
>> target. Assuming the target is a normal object, the primitive 
>> allocates a fresh array and returns the N properties.
>>
>> In the current design:
>> 1) the trap returns an array of property names (requiring O(N) 
>> physical storage cost)
>> 2) the proxy copies and verifies this array
>>
>> I think the storage costs are largely the same. However, with 
>> notification proxies, if the properties were "virtual", those 
>> properties do linger as "concrete" properties on the target. Yes, the 
>> handler can delete them later, but when is later? Should the handler 
>> schedule clean-up actions using setTimeout(0)? This somehow does not 
>> feel right.
>>
>> I like the simplicity of notification proxies, but we should think 
>> carefully what operations we turn into notifications only.
>>
>> More generally, notification proxies are indeed 
>> "even-more-direct-proxies". They make the "wrapping" use case 
>> (logging, profiling, contract checking, etc.) simpler, at the expense 
>> of "virtual objects" (remote objects, test mock-ups), which are 
>> forced to always "concretize" the virtual object's properties on a 
>> real Javascript object.
>>
>> Cheers,
>> Tom
>>
>> 2012/11/25 Mark S. Miller <erights at google.com 
>> <mailto:erights at google.com>>
>>
>>     +1. I think this is a really effective extension of the direct proxy
>>     approach, and I don't know why we didn't see it earlier. It's weird
>>     that this preserves all the flexibility of fully virtual configurable
>>     properties even though it insists that even these be made into real
>>     properties on the target. The trick is that placing a configurable
>>     property on the target doesn't commit the handler to anything, since
>>     the handler can remove or change this property freely as of the next
>>     trap.
>>
>>     Apologies again for not yet having the time to do more than skim the
>>     thread at this point. But IIRC someone already suggested a similar
>>     change to some of the imperative traps -- perhaps freeze, seal, and
>>     preventExtensions. The handler would not perform these operations on
>>     the target, only to have the proxy check it. Rather, if the trap
>>     indicates that the operation should succeed, the proxy then simply
>>     performs the operation -- or else throws. I wonder if this philosophy
>>     could be extended to some of the other imperative operations as well?
>>
>>     What expressiveness does this even-more-direct proxy approach lose?
>>     AFAICT, not much. At the same time, it should result in a *much*
>>     simpler implementation and much greater confidence that invariants of
>>     the non-proxy sublanguage are preserved by the introduction of
>>     proxies. In fact, I think it's much stronger on invariant
>>     preservation
>>     that the current direct proxies, while being much simpler.
>>
>>
>>     On Sat, Nov 24, 2012 at 6:49 PM, Dean Tribble <dtribble at gmail.com
>>     <mailto:dtribble at gmail.com>> wrote:
>>     > I am looking forward to proxies in JavaScript, and had a
>>     thought on the
>>     > issues below.  You could extend the the "direct proxy" approach
>>     for this.
>>     >
>>     > When the Proxy receives getOwnPropertyNames, it
>>     > 1) notifies the handler that property names are being requested
>>     > 2) the handler adds/removes any properties (configurable or
>>     otherwise
>>     > subject to the normal constraints) on the target
>>     > 3) upon return, the proxy invokes getOwnPropertyNames directly
>>     on the target
>>     > (e..g, invoking the normal system primitive)
>>     >
>>     > This approach appears to have consistent behavior for
>>     configurability and
>>     > extensibility. For example, the trap operation above could add
>>     configurable
>>     > properties to an extensible target, and remove them later.  It
>>     could add
>>     > non-configurable properties, but they are permanent once added,
>>     etc. Thus
>>     > there's no loss of generality.  In addition to optionally
>>     setting up
>>     > properties on the target, the handler trap above would need to
>>     indicate to
>>     > the proxy (via exception or boolean result) that the
>>     getOwnPropertyNames
>>     > operation should proceed ahead or fail.
>>     >
>>     > This extension of the "direct proxy" approach applies to all query
>>     > operations, eliminates the copying and validation overhead
>>     discussed below,
>>     > simplifies the implementation, retains full backwards
>>     compatibility, and
>>     > enables most if not all the expressiveness we might expect for
>>     proxies.
>>     >
>>     > Dean
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121126/923453a5/attachment-0001.html>


More information about the es-discuss mailing list