source.next(myDataView) - PromiseDataView
Derp. Should have been:
source.next(dataView) - PromiseIteratorResultDataView
which you kind of need anyway ; )
___
es-discuss mailing list
es-discuss@mozilla.org
Kevin Smith schrieb:
Should have been:
source.next(dataView) - PromiseIteratorResultDataView
which you kind of need anyway ; )
Wouldn't `.next()` rather need to return an
IteratorResultPromiseDataView?
Bergi
___
es-discuss mailing list
Wouldn't `.next()` rather need to return an IteratorResultPromise
DataView?
No, because the done-ness of the iteration is itself asynchronous. You
don't know whether you're done iterating until the promise resolves.
https://github.com/zenparsing/async-iteration/
From: Jason Orendorff [mailto:jason.orendo...@gmail.com]
Would it make it seem less strange if you specified the argument as a
dictionary with these properties:
{buffer:, byteOffset:, byteLength:, constructor:}
...and then casually mention that DataViews and TypedArrays both happen
Kevin Smith schrieb:
Wouldn't `.next()` rather need to return an IteratorResultPromise
DataView?
No, because the done-ness of the iteration is itself asynchronous. You
don't know whether you're done iterating until the promise resolves.
https://github.com/zenparsing/async-iteration/
Oh,
Luke Scott wrote:
Currently you can do this anyway:
const C = class {};
if (someCondition) {
C = class OtherC {};
}
You can't: const is assign-once in ES6, and only from the initialiser in
the declaration.
/be
___
es-discuss mailing list
In case it helps, the idea mooted for ES7 is that you'd add a call
handler to the class for when it is invoked without `new`:
class Point2D {
constructor(x, y) { this.x = x, this.y = y; }
[Symbol.call](x, y) { return new this.constructor(x, y); }
...
}
I used
Eric Elliott wrote:
Thanks Brendan. This is very helpful indeed! Where can I learn more
about that solution?
I know of this gist:
https://gist.github.com/wycats/0bd8f14066e44ed7b90e. Cc'ing wycats.
I assume for backwards compatibility, this will not be default
behavior, so we're going to
On 3/5/15 11:13 AM, Allen Wirfs-Brock wrote:
Editorially it would be a trivial change to make class declaration
produce immutable bindings.
Just to be clear, this would make class declarations behave differently
from builtins, both the ES kind and the IDL kind, right?
I'm not saying that's
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Boris
Zbarsky
Just to be clear, this would make class declarations behave differently from
builtins, both the ES kind and the IDL kind, right?
I think that would be true if your mental model of built-ins is that, in the
But you can support both, like this:
pull(DataView) - PromiseDataView
pull(TypedArrayView) - PromiseTypedArrayView of the same type
A view argument conveniently provides just the three pieces of
information
you need, plus a type.
I thought of that. However, I found it a
Just to be clear, this would make class declarations behave differently
from builtins, both the ES kind and the IDL kind, right?
I'm not saying that's a problem necessarily, but worth keeping in mind.
Good point. I think that we need to be looking ahead toward const class,
and leave ES6
On Mar 5, 2015, at 8:50 AM, Domenic Denicola wrote:
From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Boris
Zbarsky
Just to be clear, this would make class declarations behave differently from
builtins, both the ES kind and the IDL kind, right?
I think that would
However, the double-binding issue makes this weirder. If non-const-class
declarations were like non-const-function declarations, where there is only
one binding per defining occurrence, then I would fully agree. But this
issue of one defining occurrence creating two bindings that can diverge
On 5 March 2015 at 04:57, Brendan Eich bren...@mozilla.org wrote:
Allen Wirfs-Brock wrote:
This is novel weirdness.
In C++/Java/C# etc. you don't see it because the corresponding
declarations create immutable bindings. I agree that it would have been
nice of we could have done that.
Hi Kevin,
If it were just a question of non-const-classes being too mutable, well,
they're everywhere already ridiculously too mutable in line with most
things in JS. It would be coherent to wait for const classes to repair the
mutability of the binding at the same time it repairs the mutability
On Mar 5, 2015, at 2:52 AM, Erik Arvidsson wrote:
Traceur does not give any history on this but I also remember having this
discussion in a f2f meeting. It was all about js has always been mutable,
lets not change that. If you want immutability you have it with `const f =
class {}`.
I
Erik Arvidsson wrote:
Traceur does not give any history on this but I also remember having
this discussion in a f2f meeting. It was all about js has always been
mutable, lets not change that. If you want immutability you have it
with `const f = class {}`.
Yeah, that fits the groove laid down
On Mar 5, 2015, at 9:20 AM, Kevin Smith zenpars...@gmail.com wrote:
However, the double-binding issue makes this weirder. If non-const-class
declarations were like non-const-function declarations, where there is only
one binding per defining occurrence, then I would fully agree. But this
On Thu, Mar 5, 2015 at 1:40 PM Luke Scott l...@cywh.com wrote:
On Mar 5, 2015, at 9:20 AM, Kevin Smith zenpars...@gmail.com wrote:
However, the double-binding issue makes this weirder. If non-const-class
declarations were like non-const-function declarations, where there is only
one binding
Traceur does not give any history on this but I also remember having this
discussion in a f2f meeting. It was all about js has always been mutable,
lets not change that. If you want immutability you have it with `const f =
class {}`.
On Thu, Mar 5, 2015 at 9:51 AM Andreas Rossberg
5. Re: How to fix the `class` keyword (Allen Wirfs-Brock)
One of those possible enhancement that has been talked about is to
implicitly treat a [[Call]] of a class constructor as an implicit 'new',
just like you are suggesting.
Doesn't this need to be configurable, and Brendan Eich
22 matches
Mail list logo
