<br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Dec 6, 2012 at 2:41 PM, Jussi Kalliokoski <span dir="ltr"><<a href="mailto:jussi.kalliokoski@gmail.com" target="_blank">jussi.kalliokoski@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On Thu, Dec 6, 2012 at 8:44 PM, Rick Waldron <span dir="ltr"><<a href="mailto:waldron.rick@gmail.com" target="_blank">waldron.rick@gmail.com</a>></span> wrote:<br>

</div><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="gmail_extra"><div class="gmail_quote"><div>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.</div>


</div></div></blockquote><div> </div></div><div>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.<br></div></div></blockquote><div>

<br></div><div><br></div><div>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.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote"><div class="im">

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="gmail_extra"><div class="gmail_quote"><div>I'm absolutely not dodging the question, I answered this in a previous message, much earlier. Cascade/monocle/mustache is not a replacement here.</div></div></div>


</blockquote></div><div><br>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:<br>


<br>var obj = {<br>  foo: bar,<br>  baz: taz<br>}<br>set.add(obj)<br>return set<br><br>instead of simply:<br><br>return set.add({<br>  foo: bar,<br>  baz: taz<br>})<br><br></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="gmail_extra"><div class="gmail_quote"><div><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="gmail_quote"><div><br>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.<br>




</div></div></blockquote><div><br></div></div><div>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.</div>


</div></div></blockquote></div><div><br>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.<br>


</div><div class="im"><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra">

<div class="gmail_quote"><div>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.</div>


</div></div></blockquote></div><div><br>Sorry, about that, the meeting notes (in the part "Cascading this returns") just say:<br><br>"Supporting agreement"<br>"(Discussion to determine a criteria for making this API specification distinction)"<br>


"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."<br><br>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?<br><br></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="gmail_extra">
<div class="gmail_quote"><div></div><div>Please read everything I've written so far, it's not fair to make me constantly repeat myself in this thread.</div></div></div></blockquote></div><div><br>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.<div>


<br></div></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_extra">

<div class="gmail_quote"><div>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.</div>
</div></div></blockquote></div><div><br>Fair enough, but I fail to see the convenience in your examples.<br><br></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="gmail_extra">
<div class="gmail_quote"><div>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote"><div>

Why would you need to stuff everything in one line? </div></div></blockquote><div><br></div></div><div>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".</div>

</div></div></blockquote></div></div></blockquote><div> </div><div><br></div><div>But which kids? There certainly appears to be quite a sampling bias in your survey -- I didn't see a single actual <i>collection</i> library. Sampling their choices would be the most helpful, not <i>what the kids are doing</i>.</div>

<div><br></div><div>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.</div>

<div><br></div><div>[1] <a href="https://github.com/mauriciosantos/buckets" target="_blank">https://github.com/mauriciosantos/buckets</a></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="gmail_quote"><div>document.write() is widely implemented too, doesn't make it good or worth repeating. <br></div></div></blockquote><div> </div><div><br></div><div>That's a low blow :)</div><div> </div>

<div>  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="gmail_quote"><div>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?<br>




</div></div></blockquote><div><br></div></div><div>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).</div>


</div></div></blockquote></div><div><br>So it's taste, rather than convenience?<br></div></div></blockquote><div> </div><div><br></div><div>Is there really a difference?</div><div><br></div><div>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.</div>

</div></div>