Le 18/04/2013 05:07, Tab Atkins Jr. a écrit :
On Wed, Apr 17, 2013 at 3:57 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
A a rule of thumb, if a library does something that can not be expressed in
the its base language there is a good chance it is extending the virtual
machine of the
On Thu, Apr 18, 2013 at 4:07 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Note that Futures are entirely expressible in today's JS semantics.
(Not to say that it shouldn't be reviewed by the language gurus here,
just saying.)
JavaScript does not have an event loop (as I mentioned elsewhere)
On Thu, Apr 18, 2013 at 3:11 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
On Wed, Apr 17, 2013 at 5:50 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
That seems sensible. OTOH FutureResolver seems to make all those
methods no-ops instead. (Step 1 of each method's implementation: If
Le 18/04/2013 09:40, Anne van Kesteren a écrit :
On Thu, Apr 18, 2013 at 4:07 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Note that Futures are entirely expressible in today's JS semantics.
(Not to say that it shouldn't be reviewed by the language gurus here,
just saying.)
JavaScript does
On Thu, Apr 18, 2013 at 3:40 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Thu, Apr 18, 2013 at 4:07 AM, Tab Atkins Jr. jackalm...@gmail.com wrote:
Note that Futures are entirely expressible in today's JS semantics.
(Not to say that it shouldn't be reviewed by the language gurus here,
just
On Thu, Apr 18, 2013 at 8:48 AM, David Bruant bruan...@gmail.com wrote:
Le 18/04/2013 09:40, Anne van Kesteren a écrit :
On Thu, Apr 18, 2013 at 4:07 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Note that Futures are entirely expressible in today's JS semantics.
(Not to say that it
Le 18/04/2013 13:28, Alex Russell a écrit :
On Thu, Apr 18, 2013 at 8:48 AM, David Bruant bruan...@gmail.com
mailto:bruan...@gmail.com wrote:
Le 18/04/2013 09:40, Anne van Kesteren a écrit :
On Thu, Apr 18, 2013 at 4:07 AM, Tab Atkins Jr.
jackalm...@gmail.com
On 18/04/2013, at 14:40, David Bruant wrote:
I believe the ES spec should provide the primitives of what type of
interaction with the message queue is allowed and what isn't. This set of
primitives would obviously contain all the interactions allowed today by
HTML5.
For now, I'm aware
On 17/04/2013, at 17:46, Anne van Kesteren wrote:
If it was up to me JavaScript would just be part of the W3C
and we would not have to deal with that layer of distraction.
On 17/04/2013, at 19:48, Tab Atkins Jr. wrote:
I strongly support any efforts to move JS standardization into the
On Thu, Apr 18, 2013 at 2:00 PM, Jorge jo...@jorgechamorro.com wrote:
You guys ought to be deeply embarrassed because HTML5 is *not* your child.
I don't even
--
http://annevankesteren.nl/
___
es-discuss mailing list
es-discuss@mozilla.org
Le 18/04/2013 14:59, Jorge a écrit :
On 18/04/2013, at 14:40, David Bruant wrote:
I believe the ES spec should provide the primitives of what type of interaction
with the message queue is allowed and what isn't. This set of primitives would
obviously contain all the interactions allowed
On Thu, Apr 18, 2013 at 6:11 AM, David Bruant bruan...@gmail.com wrote:
Le 18/04/2013 14:59, Jorge a écrit :
On 18/04/2013, at 14:40, David Bruant wrote:
I believe the ES spec should provide the primitives of what type of
interaction with the message queue is allowed and what isn't. This
Note that Futures are entirely expressible in today's JS semantics.
Even setting aside the event loop, this is arguable. Futures *as
implemented in libraries today* are expressible, sure. That's a tautology.
But there are cross-cutting issues at play, as Allen explained.
In the case of
Agreed. Further, ES can't avoid specifying event loops, perhaps even in an
ES6 timeframe!! It would indeed be unfortunate if we need to specify this
in ES6. But I don't see how we can specify module loaders without doing so.
The only alternative I see is that we postpone module loaders till
On Thu, Apr 18, 2013 at 7:45 AM, Kevin Smith zenpars...@gmail.com wrote:
Note that Futures are entirely expressible in today's JS semantics.
Even setting aside the event loop, this is arguable. Futures *as
implemented in libraries today* are expressible, sure. That's a tautology.
But
GC is never required to be complete. We must allow the collector to not
collect some unreachable objects. This means that, without .done, there's
no guarantee that an unseen-rejection bug will ever get diagnosed.
Therefore we still need .done.
A perfect example of why the discussion should
From: Mark S. Miller [erig...@google.com]
GC is never required to be complete. We must allow the collector to not
collect some unreachable objects. This means that, without .done, there's no
guarantee that an unseen-rejection bug will ever get diagnosed. Therefore we
still need .done.
I
I still think the best solution to this is for the developer tools to
curate a list of unhandled rejections. Just like `window.onerror` and the
developer console work together to display unhandled exceptions, unhandled
rejections could be treated very similarly. They would appear in the
Le 18/04/2013 17:35, Kevin Smith a écrit :
Also, can someone point me to a real-world example of delayed
rejection handling?
What do you mean by delayed? If that is: a promise has been rejected
and someone later add a .fail/.catch handler to it, then I've never done
that personally. If you
Also, can someone point me to a real-world example of delayed rejection
handling?
What do you mean by delayed? If that is: a promise has been rejected and
someone later add a .fail/.catch handler to it, then I've never done that
personally.
Yes, that's what I mean. Specifically, a
On Thu, Apr 18, 2013 at 9:14 AM, Kevin Smith zenpars...@gmail.com wrote:
Also, can someone point me to a real-world example of delayed rejection
handling?
What do you mean by delayed? If that is: a promise has been rejected and
someone later add a .fail/.catch handler to it, then I've never
Hi Tab, thanks for a concrete example. From previous experience in E with
similar promises, I agree that registering handlers later is quite natural,
but I didn't have time to hunt for an example.
It would indeed be silly to require such a counter-intuitive freshness
workaround in order to avoid
I'm not sure this is a perfect match, but:
The futures library and task scheduler I've been using in my applications
for around ~5 years does unhandled error detection and delayed error
handling.
For the former, the model is that the future has an internal callback that
is fired when a consumer
(narrowing to the part that seems most productive)
On Wed, Apr 17, 2013 at 9:11 PM, Tab Atkins Jr. wrote:
On Wed, Apr 17, 2013 at 5:50 PM, Jason Orendorff wrote:
Bacon offers two equivalent ways of unsubscribing.
1. Bacon's equivalent of the StreamInit callback returns an
unsubscribe
Bacon's equivalent of EventStreamResolver.push() returns Bacon.noMore
when it finds that the number of listeners has gone to 0.
It should also be noted that streams2 in node return `false` from `push()`
when the stream is full.
Generally returning a value from `push()` as some kind of message
In preparation for tomorrow's internationalization ad-hoc meeting, I reviewed
the
Text Segmentation strawman:
http://wiki.ecmascript.org/doku.php?id=globalization:text_segmentation
Some issues go beyond internationalization and into general API design question
- I'd appreciate input from the
One bigger question: what is the DOM use case for event streams?
That is, it's very clear what the DOM use cases are for binary data streams.
(Most urgently, streaming XHR, but also perhaps unifying the many interfaces
that use object URLs as a means of connecting separate streams of data; also
I've updated my blog post with a refactoring of the API:
http://www.xanthir.com/b4PV0.
I hadn't fully appreciated the underlying abstraction of futures (that
they are the representation of async control flow), and so I was
designing the stream API in an inconsistent way. This has been fixed,
so
On Thu, Apr 18, 2013 at 4:26 PM, Jason Orendorff
jason.orendo...@gmail.com wrote:
(narrowing to the part that seems most productive)
On Wed, Apr 17, 2013 at 9:11 PM, Tab Atkins Jr. wrote:
On Wed, Apr 17, 2013 at 5:50 PM, Jason Orendorff wrote:
Bacon offers two equivalent ways of unsubscribing.
Makes sense, and thanks for clarifying!
I guess my only hesitation is that promises evolved over many years, with the
design we see in Promises/A+ today and its many implementations, including DOM
Futures, being the result of convergent evolution in library-space. While your
sugar is nice, I'd
Thanks for the overview of thrust. I had completely missed the issue of
stability before. This needs careful consideration and I have not yet made up
my mind. I understand the desire to have unstable sort for performance reasons,
but it also introduces a form of non-determinism.
Histogram can
Thanks, this indeed is an interesting use case.
Previously, I thought that using a function to map objects to a sort key is at
least as expressive as having two arrays, as a naïve implementation of the
mapping function could just be to read the appropriate value from the key array
(assuming
32 matches
Mail list logo
