(Map|Set|WeakMap)#set() returns `this` ?

Rick Waldron waldron.rick at gmail.com
Thu Dec 6 09:32:40 PST 2012

On Thu, Dec 6, 2012 at 3:48 AM, Jussi Kalliokoski <
jussi.kalliokoski at gmail.com> wrote:

> And if it comes down to precedents in the language, even Array#forEach()
> returns undefined, contrary to popular libraries out there. Let's keep some
> consistency here.

Array.prototype.map and Array.prototype.filter return newly created arrays
and as such, are chainable (and will have the same benefits as I described

// map and return a fresh iterable of values
array.map( v => ... ).values()

// map and return a fresh iterable of entries (index/value pairs)
array.filter( v => ... ).entries()

> I agree with you, fear-driven design is bad. But don't you agree that if
> there's chaining, it's better done at language level rather than having all
> APIs be polluted by `this` returns?

Who said all APIs would return `this`? We specified a clear criteria.

> After all, the APIs can't guarantee a `this` return,

Yes they can, they return what the specification defines them to return.

> since they might have something actually meaningful to return, otherwise
> we might as well just replace `undefined` with `this` as the default return
> value.

In the cases I presented, I believe that returning `this` IS the meaningful

> We could introduce mutable primitives so that meaningful return values
> could be stored in arguments, kinda like in C, but instead of error values,
> we'd be returning `this`, heheheh. :)
> I'm curious, do you have any code examples of maps/sets that could be made
> clearer by chaining?

This is incredibly frustrating and indicates to me that you're not actually
reading this thread, but still find it acceptable to contribute to the


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121206/d6428936/attachment.html>

More information about the es-discuss mailing list