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 in Python's `self` is just a casual
variable/argument, which should be passed manually anyway).
I.e. we should have `this` as `foo` in the following example:
let foo = {
bar: function () {
yield (this == foo);
}
};
let g = new Generator(foo.bar);
g.next(); // false
g.next.apply(foo,[]); // true
No, here you set `this` value of the `next` activation, not for the
context of the continuation. Notice, the state of the CC's (current
continuation) context is set only once -- at it's creation. The creation
is done (by the strawman spec) at _first_ call to `next` method. In this
creation of the CC's context, `this` value is taken from the g-object
itself (and g-object got it when was created by the call to the g-function).
Currently (in non-standardized version in SpiderMonkey), `next` method
in every single/next call doesn't change `this` value of the CC's
context, since as said, uses the same context passing it around.
I don't see currently the case when the `this` value should/could be
changed in every next entering for yielding (in other case it reminds me
Python again when you can change `self` in runtime).
So all you've done with `g.next.apply(foo,[]);` is just provided `this`
value as `foo` for the `next` method. And which is caused an exception
since `next` method is applied not for a generator object, but for the
`foo`:
g.next.apply(foo, []); // not true, but TypeError
Side note: Notice though, that current SpiderMonkey 1.8.5 shows the
following exception message: "TypeError: Generator.prototype.next called
on incompatible Object". However, `Generator` binding is not defined. So
it's good either to make `Generator` binding available, or to change the
error message. Note: it's not `Generator` function used in the previous
example, it's a built-in generators constructor:
console.log(typeof Generator); // "undefined"
let g = (function () {yield}()).next.call(null); // TypeError:
Generator.prototype.next called on incompatible global
However,
let g = foo.bar();
g.next(); // true
Could you please explain the reasoning here? I can't figure it out. To
me, g.next() has to mean that in "next", this===g.
Yes, absolutely correct. And it does mean exactly this.
However, I was talking about `this` value of the _CC's context_ (not of
the `next`s context). Perhaps it can be convenient to have a g-function
as a method of an object and use `this` as that object during all
reenters to that continuation.
I can't see a path to conclude that foo is involved.
Well, I can assume this (especially if a programmer isn't so familiar
with such a style of creating of these coroutines-generators). However,
if the programmer is familiar with that, then the information how `foo`
is involved here is taken from the code of the creation of the `g` -- at
the moment of g-function activation, i.e. when `this` value is provided
by the caller.
It's only role is to hold the property 'bar' which is a function
constructing 'g'.
As is said, we can't say exactly whether it's the only its purpose,
repeat, it's likely that `this` value normally can be used inside the
code of the g-function and refer to the needed object.
The other thing is mutable over the reentering the CC `this` value. E.g.
when we pass it to `next` and `next` then pass it throw to the CC's
context. Thus, we can't have different `this` value in every next call
to CC. But it breaks some existing scheme, e.g. with the same checking
of the `this` to be exactly the generator object in the `next` method.
And I'm not sure whether different `this` value is needed in different
reenters to the CC. Moreover, if to consider such coroutines as threads,
then I guess `this` value should be the same during the whole code of
the g-function body.
But I don't see a big need in such a wrapper. If the rules are
specified, there should be no any confusion with using call
expression for getting g-object, and then use `next` to executed the
continuation.
Perhaps we need a little user testing to see whose claims hold up.
Maybe, I'm not against it and opened to different styles and variants,
though, as I mentioned, this thing that such a generators way seems to
you unfamiliar can be just a matter of a habit.
Dmitry.
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
