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

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Thu Dec 6 10:27:54 PST 2012


On Thu, Dec 6, 2012 at 8: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.
>

Wait, sorry about that, wrote before I investigated.


>
>
>>
>>> 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/a60503d6/attachment.html>


More information about the es-discuss mailing list