On Tue, May 28, 2013 at 12:24 PM, Russell Leggett <[email protected] > wrote:
> On Tue, May 28, 2013 at 9:55 AM, Tab Atkins Jr. <[email protected]>wrote: > >> On Mon, May 27, 2013 at 9:53 AM, Russell Leggett >> <[email protected]> wrote: >> >> > On Mon, May 27, 2013 at 11:04 AM, Tab Atkins Jr. <[email protected]> >> > wrote: >> >> On Mon, May 27, 2013 at 7:29 AM, Russell Leggett >> >> <[email protected]> wrote: >> >> > I'm just going to go ahead and play stupid here. Why is it called >> chain? >> >> > I >> >> > agree one more method doesn't break anyone's brain, but I think the >> >> > confusion comes when it is not clear what a method is for and when >> they >> >> > should use it. Can anyone just try to write a really quick API doc >> for >> >> > chain >> >> > so that someone without knowledge of monads could read it? It should >> >> > hopefully be fairly obvious after reading the doc why the method is >> >> > called >> >> > chain. >> >> >> >> Yeah, it's pretty easy - the chain() method lets you "chain" one >> >> promise into another - you start with a promise, take a function that >> >> returns a promise, and return a promise from that. >> >> >> >> (Naming abstract operations is hard, but I think chain() is better >> >> than bind(). This is probably why Haskell spells it ">>=". ^_^) >> > >> > Technically speaking, though, doesn't "then" also meet that definition >> (plus >> > additional functionality)? I agree that naming abstract operations is >> hard, >> > but this just screams to me of a method that would get improperly >> > used/confused by developers. It would work like then in some cases, but >> > break unexpectedly, etc. Brendan says no name mangling, and sure it >> probably >> > shouldn't be too bad, but I think it should be on the burden of chain to >> > distinguish itself from then, and not the other way around. ES is >> already >> > filled with names like getOwnPropertyDescriptor. For the amount of use >> it >> > will get, I'm not sure it's worth a shorter, more cryptic name. >> >> "then" works equally well for promises, but I don't think it works for >> arbitrary containers - I think I'd understand "array.chain(cb)" better >> than "array.then(cb)". >> > > 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. > > 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. > I agree with Russell that `chain` is a little ambiguous when juxtaposed with `then. Around the time this conversation first kicked up I'd proposed this API and referred to what Tab calls `chain` as the "one-step resolver function". I still think `resolve` would be a pretty good, reasonably self-documenting name -- especially compared to `chain`. You can describe `then` as a recursive `resolve` and the difference should be obvious.
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
