(Map|Set|WeakMap)#set() returns `this` ?
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
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...
More information about the es-discuss