<div dir="ltr">On Tue, May 28, 2013 at 9:55 AM, Tab Atkins Jr. <span dir="ltr"><<a href="mailto:jackalmage@gmail.com" target="_blank">jackalmage@gmail.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, May 27, 2013 at 9:53 AM, Russell Leggett<br>
<div><div class="h5"><<a href="mailto:russell.leggett@gmail.com">russell.leggett@gmail.com</a>> wrote:<br>
> On Mon, May 27, 2013 at 11:04 AM, Tab Atkins Jr. <<a href="mailto:jackalmage@gmail.com">jackalmage@gmail.com</a>><br>
> wrote:<br>
>> On Mon, May 27, 2013 at 7:29 AM, Russell Leggett<br>
>> <<a href="mailto:russell.leggett@gmail.com">russell.leggett@gmail.com</a>> wrote:<br>
>> > I'm just going to go ahead and play stupid here. Why is it called chain?<br>
>> > I<br>
>> > agree one more method doesn't break anyone's brain, but I think the<br>
>> > confusion comes when it is not clear what a method is for and when they<br>
>> > should use it. Can anyone just try to write a really quick API doc for<br>
>> > chain<br>
>> > so that someone without knowledge of monads could read it? It should<br>
>> > hopefully be fairly obvious after reading the doc why the method is<br>
>> > called<br>
>> > chain.<br>
>><br>
>> Yeah, it's pretty easy - the chain() method lets you "chain" one<br>
>> promise into another - you start with a promise, take a function that<br>
>> returns a promise, and return a promise from that.<br>
>><br>
>> (Naming abstract operations is hard, but I think chain() is better<br>
>> than bind().  This is probably why Haskell spells it ">>=". ^_^)<br>
><br>
> Technically speaking, though, doesn't "then" also meet that definition (plus<br>
> additional functionality)? I agree that naming abstract operations is hard,<br>
> but this just screams to me of a method that would get improperly<br>
> used/confused by developers. It would work like then in some cases, but<br>
> break unexpectedly, etc. Brendan says no name mangling, and sure it probably<br>
> shouldn't be too bad, but I think it should be on the burden of chain to<br>
> distinguish itself from then, and not the other way around. ES is already<br>
> filled with names like getOwnPropertyDescriptor. For the amount of use it<br>
> will get, I'm not sure it's worth a shorter, more cryptic name.<br>
<br>
</div></div>"then" works equally well for promises, but I don't think it works for<br>
arbitrary containers - I think I'd understand "array.chain(cb)" better<br>
than "array.then(cb)".<br></blockquote><div><br></div><div style>I wan't suggesting using then for other containers or replacing chain with then, I was suggesting that the definition for chain on promises is a little ambiguous with the existence of 'then'. 'chain' chains promises together. "then" also chains promises together, but with some extra stuff. It puts developers in the position of wondering, "so when should I use 'then'? Why should I use it instead of 'chain'?" Given that 'then' is what they'll likely want in 99.9% (sorry for my made up statistic) of situations, I think that in the case of promises, it should be on the burden of the 'chain' method to distinguish itself from 'then'–to define itself in relation to 'then'. I think its rather similar to the discussion on arrow functions. => is what someone wants so much more often that -> was left out. It was still possible, after all, its just normal functions, but it was decided that to aid comprehension, we would encourage the happy path.</div>
<div style><br></div><div style>I'm not arguing 'chain' be removed. I'm convinced at this point its worth including, I'm just debating the method name here. Sorry if it's just bikeshedding at this point, but on the face of it, the two methods seem hard to distinguish, and while 'chain' might be a better name for some hypothetical monadic style, why not leave it up to some library to give the method a facelift. The same way that the promise API is being kept light, and will likely still be wrapped by things like the Q library for additional functionality, I expect some monadic focused library will be used if using promises in the monadic style. Worst case scenario, you just add an alias on the Promise prototype.</div>
<div><br></div><div style>- Russ</div></div></div></div>