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 <d...@deanlandolt.com> wrote:
>
>
>
> On Thu, Dec 6, 2012 at 2:41 PM, Jussi Kalliokoski <
> jussi.kallioko...@gmail.com> wrote:
>
>> On Thu, Dec 6, 2012 at 8:44 PM, Rick Waldron <waldron.r...@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@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
