A Challenge Problem for Promise Designers (was: Re: Futures)
kevin.gadd at gmail.com
Fri Apr 26 01:13:35 PDT 2013
Something that wasn't clear to me personally until reading the last few
posts: I suspect that some of the negative reaction to unwrapping/wrapping,
and the suggestion that Future<Future<T>> is a meaningful construct, comes
from the mindset of static typing - not in the sense that static types
themselves are important, but that it feels implicitly 'wrong' or
'incorrect' to write a function that is uncertain as to whether a value is
a future or not - being so incredibly haphazard about asynchronicity. This
is probably the root of my personal opinion that unwrapping isn't a good
thing. I've never seen a scenario like this in the .NET world, perhaps just
because I've never encountered code that was designed with this sort of
fundamental confusion about where asynchrony is necessary.
On the other hand, that kind of haphazardness/laziness is probably a pillar
of successful JS applications and architectures, because it lets you get
things done without arcane, perhaps inexplicable nuances of type systems
and libraries getting in your way. That definitely enables more
applications to be built faster.
Consider this my 2c regardless - the idea of functions being unsure about
whether they need to be asynchronous, because a value might be a future or
might not, and then passing that conceptual ambiguity on down the chain and
on outward into the rest of the application, does bug me. My instincts
suggest that it would lead to less maintainable code and more problems in
the wild for users, even if unwrapping itself is an incredibly useful
feature for these use cases. That is, unwrapping and wrapping are great,
but maybe the fact that they are so essential indicates a real problem that
should be addressed in the design of any standard Future primitive?
On Thu, Apr 25, 2013 at 10:40 PM, Tab Atkins Jr. <jackalmage at gmail.com>wrote:
> On Thu, Apr 25, 2013 at 8:52 PM, Mark S. Miller <erights at google.com>
> > So how does the semantics of Q(x) differ from the semantics of
> > Future.resolve(x) ?
> I suppose you tell me?
> You offered, as an example of why recursive unwrapping was useful,
> some example code that used Q(val).then(). The surrounding
> explanatory text suggested that this helped with the case where "val"
> could be either a plain value *or* a promise.
> I assumed this meant that Q() simple wraps its argument in a promise
> (like Future.accept() does), resulting in either a promise or a
> promise-for-a-promise, and .then() recursively unwrapped, so you ended
> up with the plain value at the end.
> If that's not the case, and Q() does the same "conditional wrapping"
> that Future.resolve() does, then I don't understand the point of your
> example, or how your OP in this thread supports the assertion that
> recursive unwrapping is useful.
> es-discuss mailing list
> es-discuss at mozilla.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss