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.
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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
