Experimental implementation of Object.observe & JS Utilitylibrary now available

Rick Waldron waldron.rick at gmail.com
Wed Aug 29 09:10:35 PDT 2012


On Wed, Aug 29, 2012 at 6:09 AM, Steve Sanderson <flares at 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 <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
>>
>
>
> _______________________________________________
> 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/ca2fc3b8/attachment.html>


More information about the es-discuss mailing list