On Wed, Aug 29, 2012 at 6:09 AM, Steve Sanderson <fla...@gmail.com> wrote:
> I do like François's notion of "Object.makeBindable". It would appear to > tie in with Object.observe to produce a solid, complete mechanism for > observability with dependency detection. I'll follow up in more detail in > the new thread. Nit: "Object.makeBindable" sounds like: "prepare this for bindability", but "bind" is already a concept in the language, where Function.prototype.bind creates a new function object from an existing function object, but with a BoundThis as specified by the thisArg in fn.bind( thisArg ); ... That's a point of confusion that we can easily avoid by not reusing terminology. Rick > > > On Wed, Aug 29, 2012 at 6:23 AM, Rafael Weinstein <rafa...@chromium.org>wrote: > >> Hi François, >> >> Thanks so much for your thoughtful consideration of the >> Object.observe() proposal. Here's my take on your counter-proposal: >> >> Interestingly, what you've focused on is the one thing we >> intentionally left out of the Object.observe() proposal, namely: >> observing computed properties. In that way, I don't see what you've >> proposed as an alternative, but rather supplementary. >> >> First, I'd like to point out that, while most people these days seem >> to say "databinding" and specifically mean updating a UI, there are >> important use cases which depend on observing mutations to objects >> which are entirely distinct. >> >> Note that what you've proposed, doesn't include the following abilities: >> >> 1) Discovering when new properties are added to objects -- which is >> particularly important in the case of Arrays, where you often want to >> bind to the *set* of elements in an Array >> >> 2) Knowing the order of changes which occurred -- this is important to >> many use cases, including persisting changes to domain objects and >> efficiently computing effective changes to complex data structures (a >> DOM tree implemented in JS would be one example). >> >> 3) Discovering when properties have been reconfigured -- which is >> important if your strategy for observing computed properties is >> comparatively expensive, and you need to know *when* to employ it. >> >> 4) Generally, having full knowledge of what happened to an object so >> as to able to efficiently mirror it -- which is important in some >> synchronization strategies. >> >> Ok, with that out of the way, I think the topic you've raised: >> computed properties, deserves its own thread -- so I'll start a new >> thread for that purpose and put my thoughts there. >> >> On Sun, Aug 26, 2012 at 6:14 AM, François REMY >> <fremycompany_...@yahoo.fr> wrote: >> > Here’s my take on the binding thing: >> > http://fremycompany.com/BG/2012/ECMAScript-Binding-Manager-951/ >> > >> > Key features: >> > - Do not require to have a reference on an object to bind to it >> (binding is >> > implicit and managed by the browser). >> > - Accessors, function calls and inner dependencies are managed >> > automatically. >> > - Since the browser manage most the binding wiring, it can makes tons of >> > optimizations. >> > - It’s trivial to use for developers. >> > >> > Have a look ;-) >> > >> > >> > From: Alex Russell >> > Sent: Thursday, August 23, 2012 11:47 AM >> > To: Brandon Benvie >> > Cc: ste...@stevensanderson.com ; es-discuss@mozilla.org >> > Subject: Re: Re: Experimental implementation of Object.observe & JS >> > Utilitylibrary now available >> > On Thu, Aug 23, 2012 at 7:06 AM, Brandon Benvie < >> bran...@brandonbenvie.com> >> > wrote: >> >> >> >> 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. >> > >> > >> > 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 = ) >> > >> >> >> >> 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. >> >> _______________________________________________ >> >> es-discuss mailing list >> >> es-discuss@mozilla.org >> >> https://mail.mozilla.org/listinfo/es-discuss >> >> >> > >> > >> > ________________________________ >> > _______________________________________________ >> > es-discuss mailing list >> > es-discuss@mozilla.org >> > https://mail.mozilla.org/listinfo/es-discuss >> > >> > >> > _______________________________________________ >> > es-discuss mailing list >> > es-discuss@mozilla.org >> > https://mail.mozilla.org/listinfo/es-discuss >> > >> _______________________________________________ >> es-discuss mailing list >> es-discuss@mozilla.org >> https://mail.mozilla.org/listinfo/es-discuss >> > > > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > >
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
