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

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Thu Dec 6 10:25:26 PST 2012


On Thu, Dec 6, 2012 at 7:32 PM, Rick Waldron <waldron.rick at gmail.com> wrote:

> 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
> above)
>
> // 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()
>

Of course, but that's pears and apples, .set() doesn't create a new
instance. And btw, that .values() is redundant.


>
>> 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.
>

You're dodging my question: isn't it better for the chaining to be
supported by the language semantics rather than be injected to APIs in
order to have support?


> After all, the APIs can't guarantee a `this` return,
>>
>
> Yes they can, they return what the specification defines them to return.
>

What I mean is that the not all functions in an API can return `this`
anyway (like getters), so it's inconsistent. After all, it's not a very
useful API if you can just set but not get.

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 return.
>

No, it's a generic return value if it's applied to everything that's not a
getter.


>
>> 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 discussion.
>
> https://gist.github.com/4219024
>

I'm sorry you feel that way, but calm down. I've read the gist all right
and just read the latest version, and imho it's quite a biased example,
you're making it seem harder than it actually is. For example, the last
paragraph:

( map.set(key, value), set ).keys();

// simpler:
map.set(key, value);
map.keys();

( set.add(value), set ).values();

// simpler:
set.add(value);
set.values;

( set.add(value), set ).forEach( val => .... );

// simpler:
set.add(value);
set.forEach( val => .... );

Why would you need to stuff everything in one line? This way it's more
version control friendly as well, since those two lines of code have
actually nothing to do with each other, aside from sharing dealing with the
same object. Why do you want to get all of those things from .set()/.add(),
methods which have nothing to do with what you're getting at?

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


More information about the es-discuss mailing list