Sorry, this is both foolish consistency and a boilerplate tax on users. Worse,
it removes a special form (syntax dedicated to a new primitive) that
implementations need to parse, in order to compile and optimize the function
using the primitive. We are not going to add a Generator constructor.
On 15.03.2011 21:13, John J. Barton wrote:
On 11:59 AM, Dmitry A. Soshnikov wrote:
Moreover, forgot to mention. Passing the generator function
("g-function" and "g-object" for shortness) as an argument for the
`Generator` constructor is not good for dynamically bound `this`
value (notice, that
On 11:59 AM, David Herman wrote:
P.S.:
A small change, e.g. can be to make next as a getter since it doesn't accept
arguments.
g.next; // 1
g.next; // 2
But, it's a cosmetic and actually not so needed change.
-1
The purpose of the next interface is to change the state of the iterator. A
ge
On 11:59 AM, Dmitry A. Soshnikov wrote:
Moreover, forgot to mention. Passing the generator function
("g-function" and "g-object" for shortness) as an argument for the
`Generator` constructor is not good for dynamically bound `this` value
(notice, that in Python's `self` is just a casual variabl
I agree with Dmitry on these points. In short: the new Generator(...) syntax
still requires its argument to be a generator function, so you've just added
pointless extra make-work to create one. And as Dmitry points out, you can
always implement that constructor yourself in JS.
What I think is
On 15.03.2011 20:21, David Herman wrote:
P.S.:
A small change, e.g. can be to make next as a getter since it doesn't accept
arguments.
g.next; // 1
g.next; // 2
But, it's a cosmetic and actually not so needed change.
-1
The purpose of the next interface is to change the state of the iterato
Moreover, forgot to mention. Passing the generator function
("g-function" and "g-object" for shortness) as an argument for the
`Generator` constructor is not good for dynamically bound `this` value
(notice, that in Python's `self` is just a casual variable/argument,
which should be passed manua
> P.S.:
>
> A small change, e.g. can be to make next as a getter since it doesn't accept
> arguments.
>
> g.next; // 1
> g.next; // 2
>
> But, it's a cosmetic and actually not so needed change.
-1
The purpose of the next interface is to change the state of the iterator. A
getter interface ob
On 15.03.2011 17:58, John J. Barton wrote:
On 3/14/2011 10:08 PM, Brendan Eich wrote:
On Mar 14, 2011, at 11:50 PM, John J. Barton wrote:
On 11:59 AM, Brendan Eich wrote:
However, there's no way for a generator function to return that
instance, because a generator function always implicitly r
On 3/14/2011 10:08 PM, Brendan Eich wrote:
On Mar 14, 2011, at 11:50 PM, John J. Barton wrote:
On 11:59 AM, Brendan Eich wrote:
However, there's no way for a generator function to return that instance,
because a generator function always implicitly returns a fresh generator
iterator when inv
On Mar 14, 2011, at 11:50 PM, John J. Barton wrote:
> On 11:59 AM, Brendan Eich wrote:
>> However, there's no way for a generator function to return that instance,
>> because a generator function always implicitly returns a fresh generator
>> iterator when invoked. It could store |this| in the h
On 11:59 AM, Brendan Eich wrote:
However, there's no way for a generator function to return that instance,
because a generator function always implicitly returns a fresh generator
iterator when invoked. It could store |this| in the heap, and whatever value
|this| receives is saved as part of t
On 14.03.2011 23:02, Brendan Eich wrote:
I.e. again, what I notice (and asked), is that there's no any info in the draft
spec about `this` value of the generator's context. I think it would be good to
add this information.
A generator function is still a function, and |this| binding is orthogo
> I.e. again, what I notice (and asked), is that there's no any info in the
> draft spec about `this` value of the generator's context. I think it would be
> good to add this information.
A generator function is still a function, and |this| binding is orthogonal to
yield making the surrounding
On 14.03.2011 16:51, Brendan Eich wrote:
On Mar 14, 2011, at 3:02 AM, Dmitry Soshnikov wrote:
Yep, thanks Brendan,
I filed the bug https://bugzilla.mozilla.org/show_bug.cgi?id=641436
But the thing with `this` is still interesting for me. So in this particular
case `this` should be set to `un
On Mar 14, 2011, at 3:02 AM, Dmitry Soshnikov wrote:
> Yep, thanks Brendan,
>
> I filed the bug https://bugzilla.mozilla.org/show_bug.cgi?id=641436
>
> But the thing with `this` is still interesting for me. So in this particular
> case `this` should be set to `undefined`.
No, |this| is not set
Yep, thanks Brendan,
I filed the bug https://bugzilla.mozilla.org/show_bug.cgi?id=641436
But the thing with `this` is still interesting for me. So in this particular
case `this` should be set to `undefined`. Should it be always set to
`undefined` (strict) / global object and regardless -- calling
Hi Dmitry,
It looks to me like you've just found a bug in SpiderMonkey's generator
implementation, which pre-dates the strawman:generators proposal by four+
years. Please file it in the right place: https://bugzilla.mozilla.org/. Thanks.
The bug is a regression. Here's what my Firefox 3-era JS
Hello,
I hope you can help with explaining of what is going on with `this`
value inside the body of a generator?
Consider e.g. the following case:
// infinite objects generator
let g = new function () {
this.x = 10;
while (true) {
yield;
}
};
// generate an array of 3 objects
let o
19 matches
Mail list logo
