Experimental implementation of Object.observe & JS Utilitylibrary now available

Steve Sanderson flares at gmail.com
Wed Aug 29 03:09:07 PDT 2012


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.


On Wed, Aug 29, 2012 at 6:23 AM, Rafael Weinstein <rafaelw at 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_pub at 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: steven at stevensanderson.com ; es-discuss at 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 <
> brandon at 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 at mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >>
> >
> >
> > ________________________________
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120829/74cd08a6/attachment-0001.html>


More information about the es-discuss mailing list