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

Tom Van Cutsem tomvc.be at gmail.com
Sun Nov 25 03:44:39 PST 2012


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>

> +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> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121125/52a89454/attachment.html>


More information about the es-discuss mailing list