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

Dean Landolt dean at deanlandolt.com
Thu Dec 6 12:14:26 PST 2012


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

> On Thu, Dec 6, 2012 at 8:44 PM, Rick Waldron <waldron.rick at gmail.com>wrote:
>
>> 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.
>>
>
> Yes, I apologized for that mistake already, I remembered incorrectly. I
> don't have a want to argue, just like I'm sure you don't.
>


All this misses your important "pears and oranges" point. These are not
mutable APIs, which is a key distinction. The sort method would have been a
good example of a mutable API returning `this`. But it's not exactly a
model to emulate.



>  I'm absolutely not dodging the question, I answered this in a previous
>> message, much earlier. Cascade/monocle/mustache is not a replacement here.
>>
>
> That wasn't the question I asked. Cascade/monocle/mustache aren't even
> ready yet, and are hence in no way an indication that chaining cannot be
> made a language-side construct. I believe it can and will, and at that
> point, returning this becomes completely meaningless. But (I don't see) how
> can you fix this on the language syntax side:
>
> var obj = {
>   foo: bar,
>   baz: taz
> }
> set.add(obj)
> return set
>
> instead of simply:
>
> return set.add({
>   foo: bar,
>   baz: taz
> })
>
>
>>> 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.
>>
>
> What? I'm really sorry, but I can't understand how what I said leads to
> your point. But I bet we're both wasting our time with this part, so it's
> probably best to just leave it.
>
>
>> 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.
>>
>
> Sorry, about that, the meeting notes (in the part "Cascading this
> returns") just say:
>
> "Supporting agreement"
> "(Discussion to determine a criteria for making this API specification
> distinction)"
> "Consensus... with the criteria that these methods are not simply a set of
> uncoordinated side effects that happen to have a receiver in common, but a
> set of coordinated side effects on a specific receiver and providing access
> to the target object post-mutation."
>
> With no reference to the logic behind the conclusion ("these methods are
> not simply a set of uncoordinated side effects that happen to have a
> receiver in common"). I fail to see how .set()/.add() are a special case.
> Am I missing something?
>
>  Please read everything I've written so far, it's not fair to make me
>> constantly repeat myself in this thread.
>>
>
> I agree, and I'm sorry, but I have, at least everything on this thread,
> those referred to and those that have seemed related. I'm doing my best,
> but I'm afraid I can't keep up with every thread in my inbox, and I don't
> think it's a good reason for me not to contribute at all.
>
> 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.
>>
>
> Fair enough, but I fail to see the convenience in your examples.
>
>   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".
>>
>

But which kids? There certainly appears to be quite a sampling bias in your
survey -- I didn't see a single actual *collection* library. Sampling their
choices would be the most helpful, not *what the kids are doing*.

Plus there are other alternatives I haven't seen discussed, so the design
space has barely been explored. For instance buckets [1] is a nice example
of a collection library that takes an approach more reminiscent of
javascript's existing array mutation methods -- its add method returns
`true` if the item was newly created or `false` if it was already present
in the collection -- a lot like javascript's delete operator. I'm not
necessarily advocating for this, just offering up the idea that any survey
should look closer at existing collection libraries to get a better feel
for the full design space.

[1] https://github.com/mauriciosantos/buckets



> document.write() is widely implemented too, doesn't make it good or worth
> repeating.
>


That's a low blow :)



>  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).
>>
>
> So it's taste, rather than convenience?
>


Is there really a difference?

Personally I believe only immutable APIs should ever return `this`, since
there's real value there. Mutable APIs should punish you, even if only
slightly. But that's just my taste.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121206/125dfd9b/attachment.html>


More information about the es-discuss mailing list