- From: Rick Waldron <waldron.rick@gmail.com>
- Date: Thu, 22 Nov 2012 16:34:44 -0500
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
- Message-ID: <874D9A64F7E947F9935A9244E64936B0@gmail.com>
On Thursday, November 22, 2012 at 7:32 AM, Anne van Kesteren wrote: > On Thu, Nov 22, 2012 at 3:31 AM, Rick Waldron <waldron.rick@gmail.com> wrote: > > On Wed, Nov 21, 2012 at 5:26 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > > > 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.). > > > > > Well e.g. Date seems to work differently (e.g. setHours returns > milliseconds rather than just the Date object), > > Did you intentionally ignore the fact that I identified several common "returns"? "return an expected specified value/object" Would cover the case you just described. Here's another: Array.prototype.push returns the new length. > and only the Object > examples you give match the definition I gave and since those are > relatively new I thought I'd raise the question. > > > > > (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? > > https://www.w3.org/Bugs/Public/show_bug.cgi?id=13681 > https://www.w3.org/Bugs/Public/show_bug.cgi?id=16425 > > > > > 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. > > > > > Why not? Patterns used for new APIs typically show the trend. > For exactly the reason I explained: they are unfinished. > > > > 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. > > > > > We'll see I guess. Yes, I've added this to the agenda for TC39 in-person meeting next week. Rick > > > -- > http://annevankesteren.nl/ > >
Received on Thursday, 22 November 2012 21:35:13 UTC