W3C home > Mailing lists > Public > public-script-coord@w3.org > October to December 2012

Re: ECMAScript and chaining

From: Rick Waldron <waldron.rick@gmail.com>
Date: Wed, 21 Nov 2012 21:31:57 -0500
Message-ID: <CAHfnhfofGDYWavp4yqo5BbsJP33h5B3JA1io3=gDW0gWwu==qg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "public-script-coord@w3.org" <public-script-coord@w3.org>
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.


> 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


> Cheers,
> --
> http://annevankesteren.nl/
Received on Thursday, 22 November 2012 02:32:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:07 UTC