Notification proxies (Was: possible excessive proxy invariants for Object.keys/etc??)
Tom Van Cutsem
tomvc.be at gmail.com
Mon Nov 26 11:33:25 PST 2012
2012/11/25 Allen Wirfs-Brock <allen at 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, they give a good flavor of the kinds
of compromises we'd need to make when turning to notification-only proxies.
> 1) A bit vector abstraction where individual bits are accessible as
> numerically indexed properties.
> Assume I have a bit string of fairly large size (as little as 128 bits)
> and I would like to abstract it as an array of single bit numbers where
> the indexes correspond to bit positions in the bit string. Using Proxies I
> want be able to use Get and Put traps to direct such indexed access to a
> binary data backing store I maintain. I believe that having to reify on
> the target each bit that is actually accessed would be too expensive in
> both time and space to justify using this approach.
Yes. As another example, consider a self-hosted sparse Array implementation.
The paradox here is that it's precisely those abstractions that seek to
store/retrieve properties in a more compact/efficient way than allowed by
the standard JS object model would turn to proxies, yet having to reify
each accessed property precisely voids the more compact/efficient storage
> BTW, this is a scenario where I might not even brother trying to make sure
> that Object.getOwnPropertyNames listed all of the bit indexes. I could,
> include them in an array of own property names, but would anybody really
> care if I didn't?
Well, yes and no.
Yes, in the sense that your object abstraction will break when used with
some tools and libraries. For instance, consider a debugger that uses
[[GetOwnPropertyNames]] to populate its inspector view, or a library that
contains generic algorithms that operate on arbitrary objects (say copying
an object, or serializing it, by using Object.getOwnPropertyNames).
No, in the sense that even if you would implement getOwnPropertyNames
consistently, copying or serializing your bit vector abstraction would not
lead to the desired result anyway (the copy or deserialized version would
be a normal object without the optimized bit representation) (although the
result might still be usable!)
> 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
> Yes, I also like the simplicity of notification proxies but don't want to
> give up the power of virtual objects. Maybe having both would be a
> reasonable alternative.
Brandon beat me to it, but indeed, having two kinds of proxies for the two
different use cases makes sense. Except that there's a complexity budget we
need to take into account. If we can avoid the cost of two APIs, we should.
Brandon's proposal tries to reduce the API bloat by keeping the exact same
API for both direct proxies and notification proxies, and changing the
rules dynamically based on the presence/absence of invariants. One issue I
have with that is that it will make it very hard for people writing proxies
to understand when the trap return value is ignored, and when it is not.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss