- From: Rick Waldron <waldron.rick@gmail.com>
- Date: Wed, 21 Nov 2012 21:31:57 -0500
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
Received on Thursday, 22 November 2012 02:32:45 UTC
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. 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. 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. 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/ > >
Received on Thursday, 22 November 2012 02:32:45 UTC