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

Rick Waldron waldron.rick at gmail.com
Thu Dec 6 10:44:09 PST 2012


On Thu, Dec 6, 2012 at 1:25 PM, Jussi Kalliokoski <
jussi.kalliokoski at gmail.com> wrote:

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

values() returns an iterable of the values in the array. Array, Map and Set
will receive all three: keys(), values(), entries(). Feel free to start a
new thread if you want to argue about iterator protocol.



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

I'm absolutely not dodging the question, I answered this in a previous
message, much earlier. Cascade/monocle/mustache is not a replacement here.



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

That's exactly my point. The set/add API return this, allowing
post-mutation operations to be called: such as get or any of the examples
I've given throughout this thread.


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

No one said anything about applying return this to "everything that's not a
getter". That was exactly what the criteria we have consensus on defines.
It's in the meeting notes for Nov. 29.

Please read everything I've written so far, it's not fair to make me
constantly repeat myself in this thread.




>
>
>>
>>> 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 => .... );
>
>
Of course I could've shown it as you have here, but I made examples where
the intention was to match the preceding examples illustrated in the gist.


> Why would you need to stuff everything in one line?
>

As evidenced several times throughout this thread, the pattern is widely
implemented in the most commonly used library APIs, so I guess the answer
is "The kids love it".


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

You could just as easily have them on separate lines, but in cases where it
might be desirable to immediately operate on the result of the mutation,
chaining the next method call has the net appearance of a single tasks (if
that's how a programmer so chooses to express their program).

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


More information about the es-discuss mailing list