[adding public-script-coord and Anne]
Le ven. 26 avril 2013 11:43:35 CEST, Andreas Rossberg a écrit :
On 26 April 2013 10:54, David Bruant <[email protected]> wrote:
The Priority of Constituencies [1] asks us to be remain careful about
theoretical standpoints. How does the theoretical part translates into
helping users? authors (more than what I described at [2] which is
derived
from my own experience)? implementors? specifiers?
I'm not saying the theoretical benefits don't exist, but I'd like to
see how
they translate in concretely improving my life as a developer using
promises. I've explained the benefits I see for flattening from the dev
point of view, I'd like to see the equivalent.
The argument is for regularity. On a global scale, regularity helps
the user, while exceptions, at best, are useful only locally -- an
observation that, unfortunately, is difficult to demonstrate with toy
examples.
I see. To a large extent, it's also very hard to explain benefits to
refactoring. I gave an abstract example, Mark gave a more concrete small
example, but admittedly, none really capture the benefit I have
experience in a medium-sized Node.js application.
In particular, irregularity and exceptions become a pain
when you start building abstractions, or plug together abstractions.
In other words, regularity is a prerequisite for what some people
(including me) like to call "compositionality".
Flattening for futures/promises is irregular because it means that
certain behaviour reliably exists in all cases _except_ when the input
is itself a future/promise. This may not seem like a big deal if you
use them directly. But now imagine somebody built a bigger generic
abstraction that uses futures/promises only internally. You find that
abstraction useful, and for whatever reason, need to funnel in a value
that happens to be a future.
This last sentence and especially the ambiguous "for whatever reason" is
the heart of the debate I believe. The idea expressed by Kevin Smith of
promises as featureless values is that there should be no reason for you
to funnel a value that happens to be a promise unless it's expected to
be a promise and not a non-promise value.
I have read somewhere (I can't remember where, hopefully MarkM will
confirm or say if I imagined it) that in E, if a variable contains a
promise and this promise is resolved, then the variable unwraps its
value and referencing to the variable suddenly means referencing to the
value. Promises are so deeply embedded in the language (syntax included)
that this unwrapping is seamless.
If I didn't imagine this, it'd be interesting if MarkM could expand on
that as it seems to imply that promises shouldn't be values but
lower-level than that.
Even if he confirms, it probably won't be possible to have something
that embedded in JavaScript, but I think it's an interesting perspective.
More on the idea of "there should be no reason for you to funnel a value
that happens to be a promise", that's obviously unless you're building a
promise library or tools around promises.
One thing I have been convinced by your message is that it seems
necessary to provide the lowest-level non-flattening primitives so that
people build abstractions can that consider promises as values and will
want to know about nested promise types. It should be possible, but
building such abstractions doesn't seem like the 80% use case.
Based on my experience, I remain pretty strong on the fact that
flattening is a sensible default and really has practical advantages to
large-scale development.
So, what about the following:
1) Providing lowest-level non-flattening primitives so that library
authors have fine-grained control and can build their own abstraction
where they can consider promises as values (what is missing in the
current API?)
2) The API to be used by the average devs
(then/catch/done/every/any/etc.) has flattening semantics as this is
what people with the most experience have been advocating for (people
with a different experience are still free to speak up).
This API would just happen to be one possible library that can be built
on top of 1), but one library which semantics has proven to be useful
and popular among devs.
Would that satisfy everyone?
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
