Le 24/04/2013 19:41, Andreas Rossberg a écrit :
On 24 April 2013 19:20, Mark S. Miller erig...@google.com wrote:
On Wed, Apr 24, 2013 at 10:14 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
Q and similar libraries don't actually assume that a FutureFuturex
is a Futurex.
Yes it does. Except of
I've been following es-discuss for a short amount of time.
I'm a JS dev working on a significant code base, this biases how I
perceive ES6 issues.
From my viewpoint by far the most important advancements provided by
ES6, eclipsing all others,
are modules and classes. This feeling is widely shared
Le 23/04/2013 17:52, Allen Wirfs-Brock a écrit :
On Apr 23, 2013, at 5:10 PM, Mark S. Miller wrote:
[*] I say probably to hedge my bets. The hard constraint we
absolutely require is already guaranteed by ES5: That the
[[Prototype]] of a non-extensible object cannot be mutated. Given
that, it
The focus should be on creating the best possible module system not
the best possible system that
smoothly accommodates AMD modules!
Amen to that! I would add or Node modules to your last sentence above.
The Node ship sailed, by my count, about three years ago. Competing
On Apr 25, 2013 4:00 AM, Brian Di Palma off...@gmail.com wrote:
I've been following es-discuss for a short amount of time.
I'm a JS dev working on a significant code base, this biases how I
perceive ES6 issues.
From my viewpoint by far the most important advancements provided by
ES6,
On 25 April 2013 14:56, Kevin Smith zenpars...@gmail.com wrote:
The focus should be on creating the best possible module system not
the best possible system that
smoothly accommodates AMD modules!
Amen to that! I would add or Node modules to your last sentence above.
The Node ship sailed,
I think we see a correlation -- not a 1.0 correlation, but something. Those
who've actually used promise libraries with this flattening property find
it pleasant. Those who come from either a statically typed or monadic
perspective, or have had no experience with flattening promises, generally
I think we see a correlation -- not a 1.0 correlation, but something. Those
who've actually used promise libraries with this flattening property find
it pleasant. Those who come from either a statically typed or monadic
perspective, or have had no experience with flattening promises, generally
Sam, I hope that will be the case, that's why I mentioned that I've
only been following es-discuss for a short amount of time. I wasn't
sure about the speed of response to such a substantial argument. I
waited a day to see if anyone was interested or if it generated a
discussion.
I agree that
Minutes of last week's meeting of the TC39 ad hoc on internationalization are
now available on the meetings page:
http://wiki.ecmascript.org/doku.php?id=globalization:meetings
Norbert
___
es-discuss mailing list
es-discuss@mozilla.org
I think flattening is also tied inextricably to the fact that promises are
a featureless wrapper for values. Nobody cares about promises-as-values
because of this featureless-ness. And because they are completely
uninteresting as values, programmers can think straight through to the
eventual
That's a good point. Neither the E language nor the Q library allow
subclassing of promises. The motivating reason in both cases is the
security properties that promises must provide. But you're right -- this is
an additional benefit. Promises/A+, being a minimalistic codification of
broader
Hi,
I've seen a bug report on Firefox [1] and was wondering whether
deterministic property enumeration [2] was still on the table for ES6.
Thanks,
David
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=865760
[2] http://wiki.ecmascript.org/doku.php?id=strawman:enumeration
David Bruant wrote:
Hi,
I've seen a bug report on Firefox [1] and was wondering whether
deterministic property enumeration [2] was still on the table for ES6.
My comment from that bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=865760#c5
Ignoring the SpiderMonkey threshold, we do have
I don't know what is a determinist way for enumeration and who is right
(I would be more enclined to keep the chronological order of property
settings but if the strawman says the contrary there must be a good
reason), but not knowing about #164, I wrote one day :
The HTML spec for parsing date and time values is slightly more lenient than ES.
The differences are:
- HTML allows more-than-4-digit years.
- HTML allows the seconds and milliseconds to be omitted.
- HTML allows the T in the middle to be replaced with a single space.
Can ES adopt these changes?
I'm still wading through the various issue tracker threads, but only two
concrete rationales for flattening nested Promises have emerged so far:
1 library author doesn't want nested Promises.
2 crossing Promise library boundaries can create unwanted nesting
There is little to be said about 1,
First, I appreciate you setting your thoughts down in detail. I think
this will help us move forward in the discussion.
You write in a later message:
Having said that, interoperability with existing module systems was
not the main motivation for the change in the proposal, as far as I
can
Can you point to any code in wide use that makes use of this thenables =
monads idea you seem to be implicitly assuming? Perhaps some of this generic
thenable library code? I have never seen such code, whereas the use of
thenable to mean object with a then method, which we will try to treat as
Module names play a role in three processes, in general:
1. As a way to identify local components.
2. As a way to find the physical resource that is the source code (or
object code) of the module.
3. As a way for two separately developed components to coordinate
about which module they mean.
In
On Apr 25, 2013, at 4:08 PM, Claus Reinke claus.rei...@talk21.com wrote:
You argue for a two-level system of non-lexical names to support
configuration - okay. But why does that imply you have to drop
the lexical naming altogether, instead of using a three-level system
(from external to
I've built multiple large systems using promises. A fundamental distinction
that must be clear to the client of a function is whether the function
goes async: does it return a result that can be used synchronously or
will the result only be available in a later turn. The .Net async libraries
On Thu, Apr 25, 2013 at 4:30 PM, Dean Tribble trib...@e-dean.com wrote:
I've built multiple large systems using promises. A fundamental distinction
that must be clear to the client of a function is whether the function goes
async: does it return a result that can be used synchronously or will
Hmm. I agree that the example code isn't relevant to JavaScript. For
background, the last time issues this came up for me was in the context of
a language keyword (which had other interesting but unrelated trade offs),
where it really did impose that interaction (call sites had to declare that
the
On Thu, Apr 25, 2013 at 6:03 PM, Dean Tribble trib...@e-dean.com wrote:
So what's an example
that motivates you to want to build a tower of promise types? The main one
I know of is the implementation (not use of) higher-order collection
constructs that use promises internally (e.g., the
On Thu, Apr 25, 2013 at 8:57 AM, Mark Miller erig...@gmail.com wrote:
The refactoring of putting the Q(srcP).then in the deposit method
unburdened all clients such as the buy method above from doing this
postponement themselves. The new buy method on page 13 now reads:
buy: (desc,
What is the semantics of Future.resolve?
On Thu, Apr 25, 2013 at 6:45 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Thu, Apr 25, 2013 at 8:57 AM, Mark Miller erig...@gmail.com wrote:
The refactoring of putting the Q(srcP).then in the deposit method
unburdened all clients such as the
Regarding globalization:timezoneoffsets, I just wanted to share my
anecdotal evidence that Proposal 1 (Date.withTimeZone()) works very nicely
in production -- at Bloomberg I expose this exact API (named inTimeZone()
instead of withTimeZone(), though) to developers and it has worked very
well for
On Thu, Apr 25, 2013 at 6:49 PM, Mark S. Miller erig...@google.com wrote:
What is the semantics of Future.resolve?
Creates an already-accepted future using the resolve algorithm,
which is the same magic that happens to the return value of a .then()
callback (if it's a future, it adopts the
So how does the semantics of Q(x) differ from the semantics of
Future.resolve(x) ?
On Thu, Apr 25, 2013 at 8:38 PM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Thu, Apr 25, 2013 at 6:49 PM, Mark S. Miller erig...@google.com
wrote:
What is the semantics of Future.resolve?
Creates an
I’m not sure I fully grok the use cases for FutureResolver#accept and having
FutureFuturevalue. Having to call an Unwrap extension method on a
TaskTaskT in .NET is an unfortunate necessity. Also, since Future#then
implicitly resolves a future it is difficult to return a FutureFuturevalue
from
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
32 matches
Mail list logo
