Deprecating Future's .then()

Tom Van Cutsem tomvc.be at gmail.com
Wed Jun 5 02:29:00 PDT 2013


2013/6/4 Tab Atkins Jr. <jackalmage at gmail.com>

> On Wed, Jun 5, 2013 at 12:51 AM, Mark S. Miller <erights at google.com>
> wrote:
> > I am making here only an argument that .then's result behavior should be
> > flatMap-like rather than .map-like. As for which of these the .chain camp
> > prefers for .chain's result behavior, I am neutral. But if they choose
> > .map-like, they'd be able to avoid the ugly assimilation hack.
>
> Given that .chain is just a proposed name for the monadic operation,
> which could also be called .flatMap, obviously the return value's
> behavior should be flatMap like.
>

Here's another argument I haven't heard before:

.flatMap seems like an excellent name because it immediately provides a
clue as to what it does without having to look up any docs at all. Given
that as a JS dev you know array.map(), you'll have some intuition that
.flatMap() does what map() does, with flattening (it's a pity we don't have
array.flatten() ).

Similarly, Promise.of(val) is way clearer than Promise.accept/fulfill, if
you compare it to Array.of(val) (not sure we eventually agreed to add such
a method, but I think to most JS devs it will be entirely clear what this
does, the array-equivalent of Promise.of(val) is like writing [val])

In general, while arrays in JS are not truly monadic, they are sufficiently
monadic to serve as inspiration for the promise operations.

Bikeshedding names aside, I can agree to the semantics as summarized by Tab.

Cheers,
Tom
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130605/12ae8312/attachment.html>


More information about the es-discuss mailing list