(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