>
>
> My first thought was how could someone reading the code see, that it
> is a generator?
>
Somewhat snarky answer: By documenting the code in the first place.
Yeah, I know, we all inherit other people's code and the other person never
writes comments.
I don't think this is as big of a problem in practice, however. If you're
looking at the function to understand what it does, you're certainly
looking at statements like "return $foo;" already, right? Why would "yield
$foo;" be any more stealthy?
You posit that future engineer will have to spend hours understanding what
generatorX does because it's 50+ lines long and original engineer isn't
around anymore, but if the function is so complex, then future engineer is
going to be spending hours whether or not it's a generator at all. Code
like that is just bad code. The fact that it's a generator isn't the
problem, nor is whether it's been explicitly flagged as such.
Hm... not really satisfied with that. For me this is a little bit
> unlogical, that just a simple function can return an object.
>
> So, how about implementing as a class? I mean: If it is returning a
> class, why not implement it as class?
>
> Because that misses the entire point of generators as simplified
iterators. What you suggest already exists, it's called: class foo
implements Iterator { /* iterator funcs */ } Also, it doesn't allow for
generators as class methods:
class foo {
function bar() {
yield 1;
}
}
Since this isn't Java, you can't really do:
class foo {
class bar implements generator {
function __generator() {
yield 2;
}
}
}
PS: I would like to see that yield goes hand in hand with the
> iterator-stuff.
>
Curious if you could expand on that. Generators are iterators, so not sure
what you're asking for.
-Sara
