On Thu, Dec 6, 2012 at 8:25 PM, Jussi Kalliokoski <span dir="ltr"><<a href="mailto:jussi.kalliokoski@gmail.com" target="_blank">jussi.kalliokoski@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thu, Dec 6, 2012 at 7:32 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="gmail_extra"><div class="gmail_quote"><div>Array.prototype.map and Array.prototype.filter return newly created arrays and as such, are chainable (and will have the same benefits as I described above)</div><div>

<br></div>

<div>// map and return a fresh iterable of values</div><div>array.map( v => ... ).values()</div><div><br></div><div>// map and return a fresh iterable of entries (index/value pairs)<br></div><div>array.filter( v => ... ).entries()<br>

</div></div></div></blockquote><div> </div></div><div>Of course, but that's pears and apples, .set() doesn't create a new instance. And btw, that .values() is redundant.<br></div></div></blockquote><div><br>Wait, sorry about that, wrote before I investigated. <br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_quote"><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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>

<div></div></div><div class="gmail_quote"><div>
<br>I agree with you, fear-driven design is bad. But don't you agree that if there's chaining, it's better done at language level rather than having all APIs be polluted by `this` returns? </div></div></blockquote>



<div><br></div></div><div>Who said all APIs would return `this`? We specified a clear criteria.</div></div></div></blockquote></div><div><br>You're dodging my question: isn't it better for the chaining to be supported by the language semantics rather than be injected to APIs in order to have support?<br>

</div><div class="im"><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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>After all, the APIs can't guarantee a `this` return, </div></div></blockquote><div><br></div></div><div>Yes they can, they return what the specification defines them to return.</div></div>

</div></blockquote></div><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 class="im"><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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>since they might have something actually meaningful to return, otherwise we might as well just replace `undefined` with `this` as the default return value.<br>



</div></div></blockquote><div><br></div></div><div>In the cases I presented, I believe that returning `this` IS the meaningful return.</div></div></div></blockquote></div><div><br>No, it's a generic return value if it's applied to everything that's not a getter.<br>

</div><div class="im"><div>  <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc 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>
<br>We could introduce mutable primitives so that meaningful return values could be stored in arguments, kinda like in C, but instead of error values, we'd be returning `this`, heheheh. :)<br><br>I'm curious, do you have any code examples of maps/sets that could be made clearer by chaining?<br>



</div></div></blockquote><div><br></div></div><div>This is incredibly frustrating and indicates to me that you're not actually reading this thread, but still find it acceptable to contribute to the discussion.</div><div>

<br>

</div><div><a href="https://gist.github.com/4219024" target="_blank">https://gist.github.com/4219024</a><span><font color="#888888"><br></font></span></div></div></div></blockquote></div><div><br>I'm sorry you feel that way, but calm down. I've read the gist all right and just read the latest version, and imho it's quite a biased example, you're making it seem harder than it actually is. For example, the last paragraph:<br>

<br><pre><span>(</span> <span>map</span><span>.</span><span>set</span><span>(</span><span>key</span><span>,</span> <span>value</span><span>),</span> <span>set</span> <span>).</span><span>keys</span><span>();<br>
<br>// simpler:<br>map.set(key, value);<br>map.keys();<br><br></span><span>(</span> <span>set</span><span>.</span><span>add</span><span>(</span><span>value</span><span>),</span> <span>set</span> <span>).</span><span>values</span><span>();<br>

<br>// simpler:<br>set.add(value);<br>set.values;<br><br></span><span>(</span> <span>set</span><span>.</span><span>add</span><span>(</span><span>value</span><span>),</span> <span>set</span> <span>).</span><span>forEach</span><span>(</span> <span>val</span> <span>=></span> <span>....</span> <span>);</span><br>

<br>// simpler:<br>set.add(value);<br>set.forEach( val => .... );<br><br></pre>Why would you need to stuff everything in one line? 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>

<br>Cheers,<br>Jussi<br></div></div>
</blockquote></div><br>