On Thu, Aug 23, 2012 at 7:06 AM, Brandon Benvie <span dir="ltr"><<a href="mailto:brandon@brandonbenvie.com" target="_blank" class="cremed">brandon@brandonbenvie.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I would say it is most definitely not the concern of Observe to watch reads and between accessors and Proxies we have all the tools we need for that.</blockquote>

<div><br></div><div>I think that misreads the situation. Having proxies available might work for this, but is it the right (implied) *UI* for it? I.e., if you need to do half of your work with observe() and then pivot over to proxies for the other half...that strikes me as strange. There might be good reasons not to, but saying "you can do it with what we've got" is always tautological in a turing machine = )</div>

<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> With the ability to keep present on notifications of changes via observe it's actually possible to implement a mirror that can be emit change events (by explicitly mirroring changes on the original target changes) and provide the benefits of the observe api to listeners, and then implement any kind of additional tracking on top of that either by using accessors or being a proxy.
<br>_______________________________________________<br>
es-discuss mailing list<br>
<a href="mailto:es-discuss@mozilla.org" class="cremed">es-discuss@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/es-discuss" target="_blank" class="cremed">https://mail.mozilla.org/listinfo/es-discuss</a><br>
<br></blockquote></div><br></div>