Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:62645 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 92902 invoked from network); 2 Sep 2012 01:01:10 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Sep 2012 01:01:10 -0000 Authentication-Results: pb1.pair.com header.from=smalyshev@sugarcrm.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=smalyshev@sugarcrm.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.113 as permitted sender) X-PHP-List-Original-Sender: smalyshev@sugarcrm.com X-Host-Fingerprint: 67.192.241.113 smtp113.dfw.emailsrvr.com Linux 2.6 Received: from [67.192.241.113] ([67.192.241.113:45960] helo=smtp113.dfw.emailsrvr.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 3A/8C-17065-5DFA2405 for ; Sat, 01 Sep 2012 21:01:10 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp11.relay.dfw1a.emailsrvr.com (SMTP Server) with ESMTP id 8A1EBD0CC3; Sat, 1 Sep 2012 21:01:07 -0400 (EDT) X-Virus-Scanned: OK Received: by smtp11.relay.dfw1a.emailsrvr.com (Authenticated sender: smalyshev-AT-sugarcrm.com) with ESMTPSA id E5A7FD0C19; Sat, 1 Sep 2012 21:01:06 -0400 (EDT) Message-ID: <5042AFD2.5090700@sugarcrm.com> Date: Sat, 01 Sep 2012 18:01:06 -0700 Organization: SugarCRM User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: Gustavo Lopes CC: Rasmus Lerdorf , Pierre Joye , PHP Internals References: <5040DC47.8000305@ajf.me> <5040F4D9.80206@sugarcrm.com> <5042946A.80204@sugarcrm.com> <5042A7D6.7050001@lerdorf.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Re: Are exceptions allowed in php core? From: smalyshev@sugarcrm.com (Stas Malyshev) Hi! > More importantly, there is no other satisfactory solution (except a fatal > error). foreach has no return value, so it has no other way to signal a > failure. If we used a notice or a warning here what would happen is that > code that used generators with an invalid state would, except for the > notice, work as if it had been given an empty iterator. Put another way, > it would fail with only a notice, and continue. That is a far more serious > problem. In other circumstances where we emit warnings, we usually have a > return value the caller can check for error conditions. I'm not sure I understand why you think behaving as it is an empty iterator and producing an error message is "far more serious problem". Could you explain that? For me, it behaves exactly like any other iterator would behave if you had no more useful elements in it - meaning, producing no elements. I do not understand why you think it requires immediate break of the code flow and abandoning the execution of the current function - after all, for the surrounding code the situation where iterator has no elements is a normal situation for an iterator, and iterating twice is indistinguishable - from the POV of the surrounding code - from iterating an empty iterator once. Moreover, if foreach() was supposed to have any side effects, none of these effects would happen with empty return, so there's no danger here either. So I believe the point that this condition requires immediate exit from the code flow needs some explanation. -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227