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. <jackalm...@gmail.com>wrote: > On Thu, Apr 25, 2013 at 8:52 PM, Mark S. Miller <erig...@google.com> > wrote: > > 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. > > ~TJ > _______________________________________________ > es-discuss mailing list > es-discuss@mozilla.org > https://mail.mozilla.org/listinfo/es-discuss > -- -kg
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
