Mark S. Miller wrote:
On Wed, Nov 14, 2012 at 9:25 AM, Kevin Smith <[email protected]
<mailto:[email protected]>> wrote:
I think you meant "optimally colored bikeshed," but OK.
Ouch : )
Names are important. Especially when it comes to something as
potentially confusing as promises and futures.
I agree that names are important.
1) First choice would be to use existing words, where their existing
meanings (whether nat-lang or prior technical use) clearly suggests
their intended technical meaning.
2) Second choice would be to use words whose existing meanings do not
conflict with their intended technical meaning, and where programmers do
not mistakenly assume they know the wrong meaning.
3) Like #2, but coining new words if needed.
4...) anything else is too likely to cause confusion.
When I see hardships around existing proposal, I go for something crazy.
So #4 prbably according to above terminology.
I would use .notyet (or .notYet) instead of .future for the end.
Promise for the beginning seems fine (at least, there is only one of the
promise/future pair), but I can as well see "Will" or "Shall" there.
let foo = Will(...);
let bar = foo.notyet;
and later some matching API, like
foo.done(...)/foo.wont(...)
Herby
In doing the E non-blocking promises, I looked at the history of usage
of the terms "promise" and "future". Several people had tried to use
both terms in order to make a distinction. But historically, I could not
find any consistency. For every interesting distinction, "promise" and
"future" were used by someone on each side of the distinction. However,
both were used primarily for the abstraction of designating a
yet-to-be-determined value.
Historically, the primary examples I can think of[1] of an abstraction
that bundles both the delayed designation and the ability to determine
what is designated is the logic variable (especially in concurrent logic
languages) and the Python Deferred, which inspired various JS Defferds.
If you consider this prior history of Deferreds to be significant, then
our choices of Promise/Resolver/Deferred would be following strategy #1.
Otherwise, Deferred is a new coinage and fits in strategy #3. Either
way, Scala's unfortunate choice clearly violates this history in a
confusing manner, so I'd classify it as #4. Let's not repeat Scala's
mistake.
[1] Off the top of my head now, without actually going back to the history.
- Kevin
--
Cheers,
--MarkM
------------------------------------------------------------------------
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
