Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:62268
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.139 as permitted sender)
Message-ID: <503171CB.3090609@sugarcrm.com>
Date: Sun, 19 Aug 2012 16:07:55 -0700
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20120713 Thunderbird/14.0
MIME-Version: 1.0
To: Derick Rethans <derick@php.net>
CC: Nikita Popov <nikita.ppv@gmail.com>, 
 PHP internals <internals@lists.php.net>
References: <CAF+90c_pRo6Xs2Cv9X-BN3mSnHi65gHHWzD8+yOnAPqgnWJm_w@mail.gmail.com> <alpine.DEB.2.02.1208181312390.24463@whisky.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.02.1208181312390.24463@whisky.home.derickrethans.nl>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] Generators
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

> I am against this. This is even more magic in PHP. Is it really that 
> difficult to have to mark the function with a different keyword, such as 
> "generator":

You have a point here, but "public static final generator function
foo()" sounds a bit long-winded to me... Also, we'd have then to decide
which function can be marked generator and which can't (e.g., interface
probably can't, abstract probably can't, anonymous probably can, etc.)
which adds more complexity.

Also, I think that people that complain about having to scan through
huge functions to see if they're generators or not, forget one thing:
documentation. Yes, there is a way to make the purpose of the function
understandable to a human without having him to do computer's work.
That's documentation. Undocumented code is broken code. Broken code is
not a good example when we're talking about right design.

> This should not be a concern, sure, it's annoying for the hiphop 
> developers but they chose to copy and then *chance* the PHP language for 
> their own effect.

Here I tend to agree with you - we should base on what's right for PHP,
not what HipHop or any other implementation is doing. If we can make
their lives easier - fine, but we don't have to be bound by their
decisions.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227