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

Jussi Kalliokoski jussi.kalliokoski at gmail.com
Thu Dec 6 11:41:57 PST 2012


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.

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

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


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

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


More information about the es-discuss mailing list