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

Andrea Giammarchi andrea.giammarchi at gmail.com
Thu Dec 6 13:25:19 PST 2012


Had same thoughts on returning true or false as map.delete(key) would do.

However, it's easy to have ambiguity there ... assuming the key can always
be set, 'cause even a frozen Map should be able, and it is, to set a key
internally, will true mean that key was not there ? will false mean that
key was already set or we reached maximum number of keys? Shouldn't latter
case be an error as it is for Array(Math.pow(2, 32) - 1).push("invalid
array length"); ?

This boolean return is semantic with what delete does, less semantic with
(setting[property] = value) logic thought but surely a valid possibility.

Anyway, I would like to know what other TC39 members think, cause they all
agreed already and i see this thread too dead and philosophical at this
point ... :-/

We all have made our points but it has been decided then ... well, we
should simply deal with it?

br






On Thu, Dec 6, 2012 at 12:14 PM, Dean Landolt <dean at deanlandolt.com> wrote:

>
>
>
> 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.
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121206/e591c7f7/attachment-0001.html>


More information about the es-discuss mailing list