Synchronous Object.observe but Asynchronous Object.unobserve ?

Andrea Giammarchi andrea.giammarchi at gmail.com
Fri Nov 2 09:22:41 PDT 2012


Main reason to use observe, in my opinion, is the ability to react on
changes. The moment an observer implements this "reacting logic" there's no
way it can work as expected if the object, or one of them, in the list of
records, is not observed anymore.

Let's say the object is not observed because not shadowing a DOM node for
whatever reason ... now let's say my observer gonna ask to perform so many
things because of a notification while it could simply "ignore/discards"
all those records being the object not "visible" or observed anymore.

How to make this simple ... if I switch off the TV I don't expect any eco
after ... I don't care about the program, it should not bother me.

Maybe the easiest way to avoid problems is to flag unobserved objects? But
here was my concern ... is Object.getNotifier(obj) the "official" way to
know if an object is being observed or not?


On Fri, Nov 2, 2012 at 9:14 AM, Rafael Weinstein <rafaelw at chromium.org>wrote:

> Take for example:
>
> function myCallback(recs) {
>   console.log(recs.length);
> }
>
> var obj = {};
> Object.observe(obj, myCallback);
> obj.a = 1; // enqueues changeRecord
> obj.b = 2; // enqueues changeRecord
> Object.unobserve(obj, myCallback);
> obj.c = 3; // does not enqueue changeRecord
>
> ----
>
> In the above example, myCallbacks will be invoked with two
> changeRecords and output
>
> > 2
>
> It sounds like you are worried about callbacks being delivered with
> changeRecords pointing to objects that they have stopped observing.
> This can and will happen. It's just something that users of the API
> need to understand. It doesn't strike me as a problem, but perhaps I'm
> missing something...?
>
> On Fri, Nov 2, 2012 at 5:04 PM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> wrote:
> > hey, thanks for coming back. The asynchronous unobserve in the meaning
> that
> > Object.unobserve is performed synchronously but the delivery of records
> is
> > asynchronous and performed regardless the object is not observed anymore.
> >
> > Inside the observer each record can point to an object that is no more
> > observed and I am not sure if there is a way to understand this or if the
> > observer should perform the getNotifier(obj) check.
> >
> > The way I would implement this is that when the Object.unobserve(obj) is
> > called, the queue, if any, with all previous records, is delivered at
> that
> > time, and not during the next tick.
> >
> > Thoughts?
> >
> >
> > On Fri, Nov 2, 2012 at 5:17 AM, Rafael Weinstein <rafaelw at chromium.org>
> > wrote:
> >>
> >> Andrea,
> >>
> >> I believe the example is correct. The way the API works is this:
> >>
> >> Object.observe and Object.unobserve both *synchronously*
> >> register/unregister your callback as observing/unobserving any given
> >> object. The asynchrony has to do with having changeRecords delivered
> >> -- that happens asynchronously.
> >>
> >> I don't understand the leak you are describing. Perhaps you can give a
> >> concrete example and how it goes wrong.
> >>
> >> On Thu, Nov 1, 2012 at 9:32 PM, Andrea Giammarchi
> >> <andrea.giammarchi at gmail.com> wrote:
> >> > Just wondering if this is actually meant/expected, I am talking about
> >> > the
> >> > example here:
> >> >
> >> > http://wiki.ecmascript.org/doku.php?id=harmony:observe#example
> >> >
> >> > and the fact it should show something in console while in my opinion
> >> > that
> >> > should show nothing since the Object.unobserve is called in the same
> >> > "tick"
> >> >
> >> > Then I read the algo and I wonder if this won't create many problems,
> >> > i.e.
> >> > enabling a new way to leak objects through observers that should not
> be
> >> > called once the object is not observed anymore, specially because
> >> > there's no
> >> > way to understand if the object is observed or not, isn't it?
> >> >
> >> > Thanks for any sort of clarification.
> >> >
> >> > br
> >> >
> >> > _______________________________________________
> >> > 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/20121102/b0aca5f1/attachment-0001.html>


More information about the es-discuss mailing list