Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [VOTE] Generators »

[VOTE] Generators

php.internals

Nikita Popov

14 years ago
Hi internals! I think the generators RFC has been discussed thoroughly enough by now, so I opened the vote: https://wiki.php.net/rfc/generators#vote Thanks, Nikita

Stas Malyshev

14 years ago
Hi!
> I think the generators RFC has been discussed thoroughly enough by > now, so I opened the vote: > > https://wiki.php.net/rfc/generators#vote
I think it's fine but I'd still like to put forward a proposal to reconsider the requirement for parentheses in syntax like this: $data = (yield $value); I don't see how it's particularly useful in this case, or in any case except for the array(), in which case one would want to always use parens to make the code clear, but I don't think we need to make it mandated everywhere just to cover this one (and pretty rare) case. Is there a technical reason to do that?
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

Nikita Popov

14 years ago
On Sun, Aug 26, 2012 at 10:25 PM, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> Hi! > >> I think the generators RFC has been discussed thoroughly enough by >> now, so I opened the vote: >> >> https://wiki.php.net/rfc/generators#vote > > I think it's fine but I'd still like to put forward a proposal to > reconsider the requirement for parentheses in syntax like this: > > $data = (yield $value); > > I don't see how it's particularly useful in this case, or in any case > except for the array(), in which case one would want to always use > parens to make the code clear, but I don't think we need to make it > mandated everywhere just to cover this one (and pretty rare) case. Is > there a technical reason to do that?
Yes, the parens are required for technical reasons. For yield-by-ref I have to distinguish expr_without_variable and variable, which seems to break the precedence handling. So I end up with lots of s/r conflicts. I don't know, maybe I just don't the right trick, but I see no way to support it without parens until we have an AST based parser. If anyone has a solution to this, I would have no problem dropping the requirement. Nikita PS: And yes, we really need an AST based parser :P

Jared Williams

14 years ago
> -----Original Message----- > From: Nikita Popov [mailto:nikita.ppv@gmail.com] > Sent: 25 August 2012 17:11 > To: PHP internals > Subject: [PHP-DEV] [VOTE] Generators > > Hi internals! > > I think the generators RFC has been discussed thoroughly > enough by now, so I opened the vote: > > https://wiki.php.net/rfc/generators#vote > > Thanks, > Nikita >
Hi, Just discovered another seg fault. When iterating over a generator that returns references twice it causes a seg fault. function &bind(array $keys, array &$row) { foreach($keys as $key) yield $key => $row[$key]; } $row = []; $it = bind(['a', 'b'], $row); foreach($it as $key => &$ref) echo $key; echo "\n"; foreach($it as $key => &$ref) echo $key; Jared

Nikita Popov

14 years ago
On Wed, Aug 29, 2012 at 6:21 PM, Jared Williams <jared.williams1@ntlworld.com> wrote:
> > >> -----Original Message----- >> From: Nikita Popov [mailto:nikita.ppv@gmail.com] >> Sent: 25 August 2012 17:11 >> To: PHP internals >> Subject: [PHP-DEV] [VOTE] Generators >> >> Hi internals! >> >> I think the generators RFC has been discussed thoroughly >> enough by now, so I opened the vote: >> >> https://wiki.php.net/rfc/generators#vote >> >> Thanks, >> Nikita >> > > Hi, > Just discovered another seg fault. > When iterating over a generator that returns references twice it > causes a seg fault. > > function &bind(array $keys, array &$row) > { > foreach($keys as $key) > yield $key => $row[$key]; > } > > $row = []; > $it = bind(['a', 'b'], $row); > > foreach($it as $key => &$ref) > echo $key; > echo "\n"; > foreach($it as $key => &$ref) > echo $key;
Thanks, this is now fixed. It'll throw an exception now, saying that you can't traverse an already closed generator. Nikita

Derick Rethans

14 years ago
On Wed, 29 Aug 2012, Nikita Popov wrote:
> > function &bind(array $keys, array &$row) > > { > > foreach($keys as $key) > > yield $key => $row[$key]; > > } > > > > $row = []; > > $it = bind(['a', 'b'], $row); > > > > foreach($it as $key => &$ref) > > echo $key; > > echo "\n"; > > foreach($it as $key => &$ref) > > echo $key; > > Thanks, this is now fixed. It'll throw an exception now, saying that > you can't traverse an already closed generator.
Nothing in the core throws an exception, why would this?! cheers, Derick
-- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine

Stas Malyshev

14 years ago
Hi!
>> Thanks, this is now fixed. It'll throw an exception now, saying that >> you can't traverse an already closed generator. > > Nothing in the core throws an exception, why would this?!
I'd rather have it skip foreach, maybe producing a warning/notice. It'd otherwise also be only place generators throw exceptions, which is a bit unexpected.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

Derick Rethans

14 years ago
On Wed, 29 Aug 2012, Stas Malyshev wrote:
> >> Thanks, this is now fixed. It'll throw an exception now, saying > >> that you can't traverse an already closed generator. > > > > Nothing in the core throws an exception, why would this?! > > I'd rather have it skip foreach, maybe producing a warning/notice. > It'd otherwise also be only place generators throw exceptions, which > is a bit unexpected.
Indeed. Even though yield/generator is an iterator *internally*, nothing on the language syntax side hints at that. Nothing even indicates you're using "OO" there. This is unlike the SplIterators where are you are clearly constructing fancy objects. cheers, Derick
-- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine

Nikita Popov

14 years ago
On Thu, Aug 30, 2012 at 10:27 AM, Derick Rethans <derick@php.net> wrote:
> On Wed, 29 Aug 2012, Stas Malyshev wrote: > >> >> Thanks, this is now fixed. It'll throw an exception now, saying >> >> that you can't traverse an already closed generator. >> > >> > Nothing in the core throws an exception, why would this?! >> >> I'd rather have it skip foreach, maybe producing a warning/notice. >> It'd otherwise also be only place generators throw exceptions, which >> is a bit unexpected. > > Indeed. Even though yield/generator is an iterator *internally*, > nothing on the language syntax side hints at that. Nothing even > indicates you're using "OO" there. > > This is unlike the SplIterators where are you are clearly constructing > fancy objects.
In their most trivial use (i.e. just sticking them into foreach) you won't notice that generator objects are actually, well, objects. But still you can work with them as objects and they also expose the Iterator API. E.g. you can call $gen->rewind() and this will throw an Exception (if it isn't rewindable at the moment). Do you disagree that this should throw an exception? Should it throw an error instead? If not, then why would the same rewind() call done internally in foreach not also throw an Exception? Why would that throw an error instead? It's two times the same thing, just invoked slightly different. Nikita

Nikita Popov

14 years ago
On Wed, Aug 29, 2012 at 10:10 PM, Derick Rethans <derick@php.net> wrote:
> On Wed, 29 Aug 2012, Nikita Popov wrote: > >> > function &bind(array $keys, array &$row) >> > { >> > foreach($keys as $key) >> > yield $key => $row[$key]; >> > } >> > >> > $row = []; >> > $it = bind(['a', 'b'], $row); >> > >> > foreach($it as $key => &$ref) >> > echo $key; >> > echo "\n"; >> > foreach($it as $key => &$ref) >> > echo $key; >> >> Thanks, this is now fixed. It'll throw an exception now, saying that >> you can't traverse an already closed generator. > > Nothing in the core throws an exception, why would this?!
To my knowledge all iterator-related functionality is supposed to throw exceptions (as it is a feature related to the object oriented part of PHP). At leas this is what a quick search of the code base gave me. (See http://lxr.php.net/xref/PHP_TRUNK/ext/spl/spl_dllist.c#1248 for example). Nikita

Derick Rethans

14 years ago
On Wed, 29 Aug 2012, Nikita Popov wrote:
> On Wed, Aug 29, 2012 at 10:10 PM, Derick Rethans <derick@php.net> wrote: > > On Wed, 29 Aug 2012, Nikita Popov wrote: > > > >> > function &bind(array $keys, array &$row) > >> > { > >> > foreach($keys as $key) > >> > yield $key => $row[$key]; > >> > } > >> > > >> > $row = []; > >> > $it = bind(['a', 'b'], $row); > >> > > >> > foreach($it as $key => &$ref) > >> > echo $key; > >> > echo "\n"; > >> > foreach($it as $key => &$ref) > >> > echo $key; > >> > >> Thanks, this is now fixed. It'll throw an exception now, saying that > >> you can't traverse an already closed generator. > > > > Nothing in the core throws an exception, why would this?! > > To my knowledge all iterator-related functionality is supposed to > throw exceptions (as it is a feature related to the object oriented > part of PHP). At leas this is what a quick search of the code base > gave me. (See http://lxr.php.net/xref/PHP_TRUNK/ext/spl/spl_dllist.c#1248 > for example).
"ext/spl" - SPL is not *core* language. The generators are. Don't throw exceptions from core features! Derick

Hannes Magnusson

14 years ago
On Wed, Aug 29, 2012 at 10:19 PM, Derick Rethans <derick@php.net> wrote:
> On Wed, 29 Aug 2012, Nikita Popov wrote: > >> On Wed, Aug 29, 2012 at 10:10 PM, Derick Rethans <derick@php.net> wrote: >> > On Wed, 29 Aug 2012, Nikita Popov wrote: >> > >> >> > function &bind(array $keys, array &$row) >> >> > { >> >> > foreach($keys as $key) >> >> > yield $key => $row[$key]; >> >> > } >> >> > >> >> > $row = []; >> >> > $it = bind(['a', 'b'], $row); >> >> > >> >> > foreach($it as $key => &$ref) >> >> > echo $key; >> >> > echo "\n"; >> >> > foreach($it as $key => &$ref) >> >> > echo $key; >> >> >> >> Thanks, this is now fixed. It'll throw an exception now, saying that >> >> you can't traverse an already closed generator. >> > >> > Nothing in the core throws an exception, why would this?! >> >> To my knowledge all iterator-related functionality is supposed to >> throw exceptions (as it is a feature related to the object oriented >> part of PHP). At leas this is what a quick search of the code base >> gave me. (See http://lxr.php.net/xref/PHP_TRUNK/ext/spl/spl_dllist.c#1248 >> for example). > > "ext/spl" - SPL is not *core* language. The generators are. Don't throw > exceptions from core features!
In general I agree with core language features shouldn't be throwing exceptions... But SPL definitely should never have been its own extension and most of it should have been core language features - and throwing exceptions in many of those cases makes perfect sense. We also have the case of IteratorAggregate throwing exception (which is a *core* language feature, not defined in ext/spl): $ ./sapi/cli/php -r 'class foo implements IteratorAggregate { function getIterator() { return new stdclass; } } foreach(new foo as $bar) {}' Fatal error: Uncaught exception 'Exception' with message 'Objects returned by foo::getIterator() must be traversable or implement interface Iterator' in Command line code:1 Stack trace: #0 Command line code(1): unknown() #1 {main} thrown in Command line code on line 1 -Hannes

Jared Williams

14 years ago
> -----Original Message----- > From: Hannes Magnusson [mailto:hannes.magnusson@gmail.com] > Sent: 29 August 2012 22:50 > To: Derick Rethans > Cc: Nikita Popov; Jared Williams; PHP internals > Subject: Re: [PHP-DEV] [VOTE] Generators > > On Wed, Aug 29, 2012 at 10:19 PM, Derick Rethans > <derick@php.net> wrote: > > On Wed, 29 Aug 2012, Nikita Popov wrote: > > > >> On Wed, Aug 29, 2012 at 10:10 PM, Derick Rethans > <derick@php.net> wrote: > >> > On Wed, 29 Aug 2012, Nikita Popov wrote: > >> > > >> >> > function &bind(array $keys, array &$row) { > >> >> > foreach($keys as $key) > >> >> > yield $key => $row[$key]; } > >> >> > > >> >> > $row = []; > >> >> > $it = bind(['a', 'b'], $row); > >> >> > > >> >> > foreach($it as $key => &$ref) > >> >> > echo $key; > >> >> > echo "\n"; > >> >> > foreach($it as $key => &$ref) > >> >> > echo $key; > >> >> > >> >> Thanks, this is now fixed. It'll throw an exception now,
saying
> >> >> that you can't traverse an already closed generator. > >> > > >> > Nothing in the core throws an exception, why would this?! > >> > >> To my knowledge all iterator-related functionality is supposed to
> >> throw exceptions (as it is a feature related to the object > oriented > >> part of PHP). At leas this is what a quick search of the code
base
> >> gave me. (See > >> http://lxr.php.net/xref/PHP_TRUNK/ext/spl/spl_dllist.c#1248 > >> for example). > > > > "ext/spl" - SPL is not *core* language. The generators are. Don't > > throw exceptions from core features! > > In general I agree with core language features shouldn't be > throwing exceptions... > But SPL definitely should never have been its own extension > and most of it should have been core language features - and > throwing exceptions in many of those cases makes perfect sense. > > We also have the case of IteratorAggregate throwing exception > (which is a *core* language feature, not defined in ext/spl): > > $ ./sapi/cli/php -r 'class foo implements IteratorAggregate {
function
> getIterator() { return new stdclass; } } foreach(new foo as $bar)
{}'
> > Fatal error: Uncaught exception 'Exception' with message > 'Objects returned by foo::getIterator() must be traversable > or implement interface Iterator' in Command line code:1 Stack trace: > #0 Command line code(1): unknown() > #1 {main} > thrown in Command line code on line 1 >
Speaking of IteratorAggregates and spl. I think there should be some discussion about what can be done to get the spl iterators to handle references. For instance, you cannot use CachingIterator on a reference yielding generator. And think the only method you can get it to work, feels rather kludgy. class CachingGeneratorIterator implements IteratorAggregate { private $it; function __construct(Generator $it) { $this->it = $it; } function &getIterator() { $previousKey = null; foreach($this->it as $key => &$ref) { if ($previousKey !== null) yield $previousKey => $previousRef; $previousKey = $key; $previousRef = &$ref; } if ($previousKey !== null) yield $previousKey => $previousRef; } function hasNext() { return $this->it->valid(); } } Limitations are that you have to use foreach() rather than current() to retrieve yielded references, because you can't implement an iterator with a method signature of &current(). Jared

Derick Rethans

14 years ago
On Wed, 29 Aug 2012, Jared Williams wrote:
> Speaking of IteratorAggregates and spl. > I think there should be some discussion about what can be done to get > the spl iterators to handle references.
Please do not hijack threads. Start a new one with a new subject. And do *not* reply to an old email on this list. cheers, Derick
-- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine

Pierre Joye

14 years ago
hi! On Wed, Aug 29, 2012 at 11:19 PM, Derick Rethans <derick@php.net> wrote:
> "ext/spl" - SPL is not *core* language. The generators are. Don't throw > exceptions from core features!
I would not have a problem with exceptions here. It is much cleaner than yet another warning. Cheers,
-- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Yasuo Ohgaki

14 years ago
Hi, 2012/8/30 Pierre Joye <pierre.php@gmail.com>:
> hi! > > On Wed, Aug 29, 2012 at 11:19 PM, Derick Rethans <derick@php.net> wrote: > >> "ext/spl" - SPL is not *core* language. The generators are. Don't throw >> exceptions from core features! > > I would not have a problem with exceptions here. It is much cleaner > than yet another warning.
But we have errorException for errors since PHP 5.1. http://jp.php.net/errorException Are there any technical reasons not to have exception? If there are, we should use error. If not, more arguments. BTW, I would like to change errorException behavior. It removes output buffer and make it less useful for error handling. I'll post new thread for it when I have time. Regards,
-- Yasuo Ohgaki yohgaki@ohgaki.net

Derick Rethans

14 years ago
On Thu, 30 Aug 2012, Yasuo Ohgaki wrote:
> 2012/8/30 Pierre Joye <pierre.php@gmail.com>: > > > > On Wed, Aug 29, 2012 at 11:19 PM, Derick Rethans <derick@php.net> wrote: > > > >> "ext/spl" - SPL is not *core* language. The generators are. Don't > >> throw exceptions from core features! > > > > I would not have a problem with exceptions here. It is much cleaner > > than yet another warning. > > But we have errorException for errors since PHP 5.1. > http://jp.php.net/errorException > > Are there any technical reasons not to have exception?
That is a different discussion: http://thread.gmane.org/gmane.comp.php.devel/74941 Right now, language syntax does not throw exceptions, so until we have *consensus* on error handling/reporting/exceptions, the new yield keyword with generators should *not* throw exceptions either! cheers, Derick
-- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine

Gustavo Lopes

14 years ago
On Wed, 29 Aug 2012 22:10:52 +0200, Derick Rethans <derick@php.net> wrote:
> On Wed, 29 Aug 2012, Nikita Popov wrote: > >> > function &bind(array $keys, array &$row) >> > { >> > foreach($keys as $key) >> > yield $key => $row[$key]; >> > } >> > >> > $row = []; >> > $it = bind(['a', 'b'], $row); >> > >> > foreach($it as $key => &$ref) >> > echo $key; >> > echo "\n"; >> > foreach($it as $key => &$ref) >> > echo $key; >> >> Thanks, this is now fixed. It'll throw an exception now, saying that >> you can't traverse an already closed generator. > > Nothing in the core throws an exception, why would this?! >
This is not accurate. All the iterators throw exceptions on similar situations. Generators are iterators, so I see no deviation from the norm here.
-- Gustavo Lopes

Derick Rethans

14 years ago
On Wed, 29 Aug 2012, Gustavo Lopes wrote:
> On Wed, 29 Aug 2012 22:10:52 +0200, Derick Rethans <derick@php.net> wrote: > > > On Wed, 29 Aug 2012, Nikita Popov wrote: > > > > > > function &bind(array $keys, array &$row) > > > > { > > > > foreach($keys as $key) > > > > yield $key => $row[$key]; > > > > } > > > > > > > > $row = []; > > > > $it = bind(['a', 'b'], $row); > > > > > > > > foreach($it as $key => &$ref) > > > > echo $key; > > > > echo "\n"; > > > > foreach($it as $key => &$ref) > > > > echo $key; > > > > > > Thanks, this is now fixed. It'll throw an exception now, saying that > > > you can't traverse an already closed generator. > > > > Nothing in the core throws an exception, why would this?! > > This is not accurate. All the iterators throw exceptions on similar > situations. Generators are iterators, so I see no deviation from the > norm here.
Nothing shows that they are. In any example I saw, I don't even see any OO syntax/functionality. For me, "yield" is a core syntax *keyword*, and hence: no exceptions. cheers, Derick
-- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine

Andrew Faulds

14 years ago
Derick Rethans <derick@php.net> wrote:
>Nothing shows that they are. In any example I saw, I don't even see any > >OO syntax/functionality. For me, "yield" is a core syntax *keyword*, >and >hence: no exceptions. >
I was unware PHP was a purist, non-OOP language. What is "OO syntax" anyway? Why can the core not use high-level language constructs too? Yield is core syntax, but it produces a function returning a generator, which is an object, and since Iterators use Exceptions, it would be stupid for Generators, which *are* a class of Iterator, not to.
-- Sent from my Android phone with K-9 Mail. Andrew Faulds http://ajf.me/

Lester Caine

14 years ago
Andrew Faulds wrote:
> > Derick Rethans<derick@php.net> wrote: >> >Nothing shows that they are. In any example I saw, I don't even see any >> > >> >OO syntax/functionality. For me, "yield" is a core syntax*keyword*, >> >and >> >hence: no exceptions. >> > > I was unware PHP was a purist, non-OOP language. What is "OO syntax" anyway? Why can the core not use high-level language constructs too? > > Yield is core syntax, but it produces a function returning a generator, which is an object, and since Iterators use Exceptions, it would be stupid for Generators, which*are* a class of Iterator, not to.
Actually - shouldn't the discussion on use of Exceptions be sorted out prior to adding them piecemeal into new functions. If I had a vote I'd certainly ask that any implementation of generators respected the 'core' code practices. Iterators are simply an add-on in my design manual and can be avoided - as can yield - but yield is being brought in at a level where it is more invasive? Error handling is another growing minefield and needs to be tidied up before this sort of creep makes it impossible to remove if that is the preferred option? There needs to be a formal agreement on Exceptions before they are pushed out further.
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

Morgan L. Owens

14 years ago
On 2012-08-30 20:39, Derick Rethans wrote:
> On Wed, 29 Aug 2012, Gustavo Lopes wrote: > >> On Wed, 29 Aug 2012 22:10:52 +0200, Derick Rethans <derick@php.net> wrote: >> >>> >>> Nothing in the core throws an exception, why would this?! >> >> This is not accurate. All the iterators throw exceptions on similar >> situations. Generators are iterators, so I see no deviation from the >> norm here. > > Nothing shows that they are. In any example I saw, I don't even see any > OO syntax/functionality. For me, "yield" is a core syntax *keyword*, and > hence: no exceptions. > > cheers, > Derick >
I'm generally of the same opinion as you - issue a warning and skip the second loop - but for the fact that the "idiomatic" use <?php foreach(generator() as $k => $item) { ... } ?> is equivalent to the more explicit "manual" use <?php $generator = generator(); $generator->rewind(); while($generator->valid()) { $k = $generator->key(); $item = $generator->current(); ... $generator->next(); } ?> Since explicit control of generators can be useful, they won't necessarily be wrapped in the foreach() idiom; would not exceptions be the expected behaviour then? There might be a compromise - trigger a warning in idiomatic use, an exception in manual use - but that leaves a nasty taste in the mouth and would just cause more problems later.

Julien Pauli

14 years ago
Heh, we face a true problem here, and it's deeper than just "should generators throw exception or not". Adding Derick's notice, -which is true- it becomes "should Core features start throwing Exception knowing we've been fighting to prevent that for years ?". Generator use objects, right ; but as core features using a core syntax keyword, one might not expect that to throw an Exception, I so agree here with Derick idea, at least : with the things as they are nowadays. We already have a topic about new error handling into ML , and I think we really really *should* start agreeing (RFC, patches and votes) about a new "error" handling process inside PHP, as more and more features we'll add to the language may be somehow object oriented in the future. If the new internal error management we'll debate and agree with is going to break BC (which, IMO, will), then we should merge it to our next major (6.0 ?) And what about SPL ? Which really should join Core features as well, it has nothing to do into an extension anymore :-P Julien.Pauli On Fri, Aug 31, 2012 at 2:36 AM, Morgan L. Owens <packrat@nznet.gen.nz> wrote:

Nikita Popov

14 years ago
On Sat, Aug 25, 2012 at 6:10 PM, Nikita Popov <nikita.ppv@gmail.com> wrote:
> Hi internals! > > I think the generators RFC has been discussed thoroughly enough by > now, so I opened the vote: > > https://wiki.php.net/rfc/generators#vote > > Thanks, > Nikita
The vote ended with 24 in favor and one against. As such the RFC is accepted. If somebody could give me Zend karma I can merge the branch :) Nikita

Lester Caine

14 years ago
----- Original message -----
> On Sat, Aug 25, 2012 at 6:10 PM, Nikita Popov <nikita.ppv@gmail.com> > wrote: > > Hi internals! > > > > I think the generators RFC has been discussed thoroughly enough by > > now, so I opened the vote: > > > > https://wiki.php.net/rfc/generators#vote > > > > Thanks, > > Nikita > > The vote ended with 24 in favor and one against. As such the RFC is > accepted. > > If somebody could give me Zend karma I can merge the branch :)
Now are you just going to blast everything in are take note of the objections to exceptions? I still think this needs the documentation completely reworked without the incorrect examples as to why it was supposedly needed!

Gustavo Lopes

14 years ago
On Sat, 01 Sep 2012 18:02:40 +0200, Nikita Popov <nikita.ppv@gmail.com> wrote:
> The vote ended with 24 in favor and one against. As such the RFC is > accepted. >
I've merged Nikita's branch in 53351d0. As to the "exception objection": the behavior of throwing exceptions on illegal state was written on the RFC when voting opened, and the RFC was accepted almost unanimously. As the proposal was accepted as such, I saw no valid reason not to merge. In fact, changing the proposal after it was voted on would be much more objectionable. Derick argues this is some sort of tacit change of the design rules of the language, with the objection against exception throwing relying also on the user's ignorance that generators return a Generator object (though he also chose not to vote against the proposal). I don't find his arguments persuasive, but, in any case, the issue can be adjudicated by the community through an RFC that establishes either a clear general policy for exception throwing or handles just this particular case.
-- Gustavo Lopes

Stas Malyshev

13 years ago
Hi!
> illegal state was written on the RFC when voting opened, and the RFC was > accepted almost unanimously. As the proposal was accepted as such, I saw > no valid reason not to merge. In fact, changing the proposal after it was > voted on would be much more objectionable.
I definitely did not agree to using exceptions, though I support the rest of it. I'm completely fine with merging it but just for the record I'd like to note that accepting it doesn't mean we will not tweak it or change some fine details of it - like how we handle some error situations.
-- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227

Derick Rethans

13 years ago
On Sat, 1 Sep 2012, Stas Malyshev wrote:
> > illegal state was written on the RFC when voting opened, and the RFC > > was accepted almost unanimously. As the proposal was accepted as > > such, I saw no valid reason not to merge. In fact, changing the > > proposal after it was voted on would be much more objectionable. > > I definitely did not agree to using exceptions, though I support the > rest of it.
Same here.
> I'm completely fine with merging it but just for the record I'd like > to note that accepting it doesn't mean we will not tweak it or change > some fine details of it - like how we handle some error situations.
Right, so lets remove that exception throwing! cheers, Derick

Pierre Joye

13 years ago
hi Derick, On Sun, Sep 2, 2012 at 7:10 PM, Derick Rethans <derick@php.net> wrote:
> On Sat, 1 Sep 2012, Stas Malyshev wrote: > >> > illegal state was written on the RFC when voting opened, and the RFC >> > was accepted almost unanimously. As the proposal was accepted as >> > such, I saw no valid reason not to merge. In fact, changing the >> > proposal after it was voted on would be much more objectionable. >> >> I definitely did not agree to using exceptions, though I support the >> rest of it. > > Same here. > >> I'm completely fine with merging it but just for the record I'd like >> to note that accepting it doesn't mean we will not tweak it or change >> some fine details of it - like how we handle some error situations. > > Right, so lets remove that exception throwing!
Let clear that topic once and for all (almost) instead. I think some guidance to help to chose on a case by base whether exceptions should be used or not. Let discussion that in the other thread. Cheers,
-- Pierre @pierrejoye | http://blog.thepimp.net | http://www.libgd.org

Matt Ficken

13 years ago
I have created a single build combining the Generator RFC and the property getter/setter RFC. On Windows, one of the Generator tests fails (tests\generators\clone_with_stack.phpt), but all pass on Linux. There are some regressions due to the branch not included many of the recent fixes for Windows. The PHP on Windows releases are now built with Profile-Guided-Optimization(PGO) which optimizes compiled code for better performance in frequently used blocks. I have also created a PGO build that combines both RFCs. It has the same pass rate as the first, non-PGO build of both RFCs. I have posted the binary builds, source code and output from run-test here: http://131.107.220.66/build/RFC/ Implementing both RFCs together along with PGO on Windows works well enough for both RFCs to be implemented in php-next. Cheers -Matt