Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:42614
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.142.185 as permitted sender)
DomainKey-Status: bad
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:cc:content-type
         :content-transfer-encoding;
        b=CZJFTBX/kfAjQsQXlw8rgb/wQ9ip+N07y8E2aFa571JURZ/WTCDdSpSrKukhYfWpjG
         Ww/+tfSzKdKvKzjfHKK0fcChEG3CUk2kCxZwo7WkKd+EpPp78aX+TY6ZcW13gS05ZZvw
         WGeyZ1NZxuSKfTG0RpKfruhE0yksRVNOpSsyg=
MIME-Version: 1.0
Sender: xuefer@gmail.com
In-Reply-To: <e666c3890901130629r3859f83fib8af6a9d6c6a3dfa@mail.gmail.com>
References: <28139bc0901130430s32b0a156r792c39d2393e20c6@mail.gmail.com>
	 <e666c3890901130629r3859f83fib8af6a9d6c6a3dfa@mail.gmail.com>
Date: Wed, 14 Jan 2009 10:20:00 +0800
Message-ID: <28139bc0901131820n66c71ee3yb66aa103607f1bba@mail.gmail.com>
To: Etienne Kneuss <webmaster@colder.ch>
Cc: PHP Developers Mailing List <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] generator/yield operator feature request
From: moo.tinys@gmail.com ("moo.tinys")

> On the contrary, It will most likely require a lot of changes to
> provide structures that are able to store their execution context to
> be able to resume it later. I.e.
>
> function foo() {
>    error_reporting(0);
>    yield "foo";
>    trigger_error("foo", E_NOTICE);
>    yield "bar";
> }
> $e = false;
> error_reporting(E_ALL);
> foreach (foo() as $b) {
>     if (!$e) { $e = true; error_reporting(E_ALL); }
> }
>
> 1) will the error be thrown?
> 2) what will the error_reporting value be after the execution of the function ?
>
> error_reporting is a setting that is shared, and here you'd like to
> resume the execution using the old context (error_reporting = 0) to
> continue the function, affecting the outer context, which will stick
> after the function ends? Or do you plan to keep both contexts
> completely separated and create inconsistencies?
>
>> pro: "simple" to implement in ZendEngine, see note 2 aboive
>> con: -
>>
>> let's see what will yeild/generator looks like:
>>  1. require saving function calling context (not call stack)
>> con(was): there was no way to save it, we had to implement it first
>> con(now): no con, implemented already in 5.3
>
> How is that implemented already in 5.3 ?
i haven't dig deep into how closure is implemented, but it's a big
step forward, yield/generator function is another minor step base on
or smilar as closure
>
>>  2. just 1 function, yield at any where in the body
>> pro: much more readable than Iterator
>> con: "yield" is now reserved keyword
>> example:
>> function foo($space_and_new_line = false)
>> {
>>  yield "hello";
>>  if ($space_and_new_line) {
>>    yield " ";
>>  }
>>  yield "world";
>>  if ($space_and_new_line) {
>>    yield PHP_EOL;
>>  }
>> }
>>
>> $g = foo(true); // function foo() is not called here
>> foreach ($g as $i) { // function foo() IS called here
>>  echo $i;
>> }
>>
>> function filter($g, $regex)
>> {
>>  foreach ($g as $baa) {
foreach ($g as $i) { // <- correction, and sorry, here's the right version
>>    if (preg_match($regex, $i)) {
>>     return true;
yield $i; // <- correction
>>    } // if
>>  } // foreach
>> }
>>
>> $g = foo(true);
>> foreach (filter($g, "^\\w+$") as $i) {
>>  echo $i; // now letters only
>> }
>
> That example looks wrong(and I hope it is):
> - $i is not defined in the scope of filter()
> - filter() returns true or null. You can't iterate on such values.
>
> Also, could you provide an example where this construct is actually useful ?
every Iterator class can be rewritten into more simpler form in
generator function
every generator function can also be rewritten into more
simpler/complexer form in Iterator class (most of the time, it's more
complexer)

for more complex code, i have to write it in pseudo code
function fetch_items()
{
foreach (array(some builtin constant items here) as $item) {
  yield $item;
}
foreach (get_version1_urls() as $v1url) {
  $content = file_get_contents($v1url);
  foreach (parse_version1_content($content) as $item) {
   yield $item;
  }
}
foreach (get_version2_urls() as $v2url) {
  $content = file_get_contents($v2url);
  foreach (parse_version2_content($content) as $item) {
   yield $item;
  }
}
}

yes, as i said you can rewrite it in iterator

iterator class is a stateful iteratable implemented in class, while
generator function is a stateful iteratable implemented in function
(stateful version of function)
if iterator class looks like a state machine that split code into
multiple function/methods, generator function looks like thread base
deisgn that can yield at some point which is sure more easier to write
and understood
you're skilled programmer like i am, understanding/writing iterator
class is no big deal, but generator can make life much better for vast
of php guys
>
> The example you provided doesn't demonstrate anything, as it can be
> implemented in a far easier way using:
>
> function foo($s) {
>    return $s ? array('hello', ' ', 'world', PHP_EOL) : array('hello', 'world');
> }
this is not in iterator class "framework"
>
> foreach(foo() as $word) {
> ...
> }
>
> additionally,  SPL's filterIterator and arrayiterator can be used to
> implement a filtered iteration on the array.
they're already implemented. yes, my example can be rewritten by
reusing already implemented iterator class, but why not think about a
case when ppl have to implemented their own iterator class? or have we
all possible iterator class implemented already?
>
>>
>> $g = foo(true);
>> echo $g(); // same as: echo $g->value(); $g->next(); this is not in
>> python, neither in php iterator
>> echo $g();
>> echo $g();
>
> This syntax is definitely not self-explanatory, and will make things
> really hard to understand.
well.. i'm not sure if this is useful either, just a thought when i
bring this topic up :)

>
> I'm skeptic at what value this construct would really add to PHP. And
> my guess is, it will not be worth the trouble implementing it.
thanks for your time