<div class="gmail_quote">2012/11/25 Allen Wirfs-Brock <span dir="ltr"><<a href="mailto:allen@wirfs-brock.com" target="_blank">allen@wirfs-brock.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><div class="im"><div><br></div></div><div>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.</div>
</div></div></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>1) A bit vector abstraction where individual bits are accessible as numerically indexed properties. </div>
<div><br></div><div>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.</div>
</div></div></blockquote><div><br></div><div>Yes. As another example, consider a self-hosted sparse Array implementation.</div><div><br></div><div>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 of properties.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div>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?  </div>
</div></div></blockquote><div><br></div><div>Well, yes and no.</div><div><br></div><div>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).</div>
<div><br></div><div>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!)</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="im"><blockquote type="cite"><div><br></div><div>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.</div>
</blockquote><div><br></div></div><div>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.</div></div></div>
</blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div>Cheers,</div><div>Tom</div></div>