Linking to some Twitter discussion related to this:
https://twitter.com/bradleymeck/status/436371508005326850
On Thu, Feb 20, 2014 at 3:03 AM, David Bruant bruan...@gmail.com wrote:
Le 20/02/2014 06:39, Brendan Eich a écrit :
Bradley Meck wrote:
If I am reading the spec right (and I may
I was going to respond via github to this issue comment, but I figured the
answer probably was of interest to a broader audience. So go and read
https://github.com/Raynos/observ-hash/issues/2#issuecomment-35857671 and then
continue.
Rev22 of the ES6 draft introduced the concepts of Tasks and
On Mon, Feb 24, 2014 at 9:45 AM, Allen Wirfs-Brock al...@wirfs-brock.comwrote:
I was going to respond via github to this issue comment, but I figured
the answer probably was of interest to a broader audience. So go and read
https://github.com/Raynos/observ-hash/issues/2#issuecomment-35857671
Ok, so I've read most of the Promise.cast/Promise.resolve thread and
it's gone back and forth and branched in topic several times...but now
I'm a bit confused as to where we sit (and navigating that thread again
isn't the most exciting idea). So can someone who's been following that
thread
The latest draft doesn't seem to specify (or I can't find) where the Loader and
Module constructor object will be accessible from. Will they be available as
properties of the global object, as properties of System or as properties of
Reflect?
Thank you,
-
On Mon, Feb 24, 2014 at 10:13 AM, Jeff Morrison lbljef...@gmail.com wrote:
Ok, so I've read most of the Promise.cast/Promise.resolve thread and
it's gone back and forth and branched in topic several times...but now I'm
a bit confused as to where we sit (and navigating that thread again isn't
On Feb 24, 2014, at 10:11 AM, Mark S. Miller wrote:
On Mon, Feb 24, 2014 at 9:45 AM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
...
Hi Allen, I agree that it's good to keep these levels separate by adopting
distinct terminology. However, using the term Task to avoid confusion with
Here is an idea for easily defining an iterator with holes, so that
`Array.from` could reconstruct a sparse array from an iterable:
Iterators yield IteratorResult objects, which are of the form `{done:
boolean, value: any}`. The idea is to produce results of the form `{done:
true}` (omitting
You presumably mean ... of the form `{done: false}`
The possibility of a yield without an assignment expression meaning
yield a hole might be left open for the future (so some clients would
treat it the same as yield undefined, but those who care to distinguish
could do). There would need to
On 24 February 2014 23:30, Nick Krempel ndkrem...@google.com wrote:
The possibility of a yield without an assignment expression meaning
yield a hole might be left open for the future (so some clients would
treat it the same as yield undefined, but those who care to distinguish
could do).
Le 25 févr. 2014 à 00:32, Nick Krempel ndkrem...@google.com a écrit :
On 24 February 2014 23:30, Nick Krempel ndkrem...@google.com wrote:
The possibility of a yield without an assignment expression meaning yield
a hole might be left open for the future (so some clients would treat it the
On Feb 24, 2014, at 4:18 PM, Claude Pache wrote:
Personally, I consider that the impossibility to yield a hole must be
considered as a feature, not a bug. Holes are useful in order to have
consistent results for `Array.from([1, , 3])` (i.e., getting an exact copy),
but their use should
Le 25 févr. 2014 à 01:54, Allen Wirfs-Brock al...@wirfs-brock.com a écrit :
On Feb 24, 2014, at 4:18 PM, Claude Pache wrote:
Personally, I consider that the impossibility to yield a hole must be
considered as a feature, not a bug. Holes are useful in order to have
consistent results
On Mon, Feb 24, 2014 at 4:24 PM, Claude Pache claude.pa...@gmail.com wrote:
Indeed, but the question was about producing/forwarding holes rather than
skip them, so that, e.g., `Array.from` could replace the elements at the
correct positions.
You'd probably want `Array.fromEntries` then, and
14 matches
Mail list logo
