Bug 16425 - MutationObserver::observe/disconnect should return mutationobserver itself
Summary: MutationObserver::observe/disconnect should return mutationobserver itself
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: DOM (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: Anne
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2012-03-18 23:08 UTC by Olli Pettay
Modified: 2012-11-22 21:55 UTC (History)
6 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Olli Pettay 2012-03-18 23:08:22 UTC
This was discussed and somewhat agreed end of September.
Allows one to do
        .observe(node1, {...})
        .observe(node2, {...});
Comment 1 Anne 2012-03-18 23:27:00 UTC
We have implemented this pattern in no API whatsoever to date. It was a conscious omission.
Comment 2 Olli Pettay 2012-03-18 23:28:51 UTC
Ok. I don't care too much. 
I personally don't like that coding style at all
(but one doesn't need to use that ugly style.)
Comment 3 Jonas Sicking 2012-03-19 19:33:43 UTC
Anne: "we haven't used this pattern anywhere else" is a terrible reason. Up until recently we also had never used dictionaries.

I hope that there's a better reason that than, such as that it fosters bad development practices, that it's bad for performance, or that it can result in buggy code?

Reopening since so far no good reason has been made.
Comment 4 Ms2ger 2012-03-19 21:30:36 UTC
AIUI, the plan was to wait for ES to provide something to address this pattern for *all* APIs, rather than trying to implement it just for a couple of new APIs. Returning self also prevents us from returning something meaningful (even though we currently don't in this case).
Comment 5 Jonas Sicking 2012-03-19 22:10:08 UTC
What would this look like to be API-wide? Are we talking about something like the now-defunct 'with' operator? Has anyone check with TC39 if that is in the stars at all before we rely on them?
Comment 6 Anne 2012-03-19 23:35:54 UTC
You generally need a good reason for doing something, not for not doing it.
Comment 7 Jonas Sicking 2012-03-20 00:34:59 UTC
The good reason would be that it makes it much easier to observe several parts of the DOM.
Comment 8 Olli Pettay 2012-03-20 00:51:13 UTC
"much" is quite strong word.

var o = new MutationObserver(callback);
o.observe(node1, {...});
o.observe(node2, {...});
o.observe(node3, {...});

is not much longer than
var o = new MutationObserver(callback);
o.observe(node1, {...})
 .observe(node2, {...})
 .observe(node3, {...});
Comment 9 Jonas Sicking 2012-03-20 00:54:50 UTC
Though it means that you can avoid the temporary:

(new MutationObserver(callback))
  .observe(node1, {...})
  .observe(node2, {...})
  .observe(node3, {...});
Comment 10 Anne 2012-11-21 21:28:26 UTC
Once ECMAScript adopts this pattern we can consider it. (See also bug 13681 comment 5.)
Comment 11 Rafael Weinstein 2012-11-21 21:57:41 UTC
What would "once" look like? Object.freeze/preventExtensions/etc... are already spec'd to return the object.
Comment 12 Anne 2012-11-21 22:17:19 UTC
Well, e.g. Map.set() returns undefined. Maybe that's what design by committee looks like?
Comment 13 Rafael Weinstein 2012-11-21 22:21:47 UTC
We recently changed the Object.observe/unobserve spec calls to return object, for consistency with Object.freeze/etc... I think there's a clear move in that direction.
Comment 15 Rick Waldron 2012-11-22 21:55:01 UTC
FWIW, the new Object.observe API has recently been updated to return the target object.