- From: Mark S. Miller <erights@google.com>
- Date: Thu, 22 Nov 2012 11:52:11 -0800
- To: Rick Waldron <waldron.rick@gmail.com>
- Cc: Anne van Kesteren <annevk@annevk.nl>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Wed, Nov 21, 2012 at 6:31 PM, Rick Waldron <waldron.rick@gmail.com> wrote: > On Wed, Nov 21, 2012 at 5:26 PM, Anne van Kesteren <annevk@annevk.nl> wrote: >> >> Hi, >> >> I was wondering if the plan of TC39 is to start returning the object >> on which a method was invoked if that method would otherwise just >> return undefined. No, though Rick just placed this on the agenda to discuss at the upcoming meeting. >> E.g. this seems to be what Object.freeze() and >> Object.preventExtensions() do. It's also a somewhat popular API idiom >> in jQuery and the like (see also method chaining, fluent interface). > > > I'm not sure what you mean by "start"—this is already the prevailing > practice. It is most definitely not. Let's discuss more at the upcoming meeting. > APIs either return an expected specified value/object, the target > object (in the case of static built-ins, eg. Object.freeze(o); // o ) or a > new specified object (eg. Array.prototype.{ filter, map } etc.). > > >> >> >> (The reason I'm asking is that I just WONTFIXED two bugs asking for >> that stating that ECMAScript did not have this pattern either and I >> was confronted with the above. Good, thanks. > > > Links? > >> >> I had been looking at Map.set() >> myself.) > > > The ES6 Map, Set and WeakMap API specifications are still in development and > probably shouldn't be used to make decisions like this. > > In this particular case there is no rationale documented for these not > returning the object they are called from, so it's still open for > discussion, ie. Map.prototype.set, Set.prototype.add and > WeakMap.prototype.set. > > Rick > > >> >> >> Cheers, >> >> >> -- >> http://annevankesteren.nl/ >> > -- Cheers, --MarkM
Received on Thursday, 22 November 2012 19:52:38 UTC