Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56371
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 207.97.245.113 as permitted sender)
Message-ID: <4EC57857.6030904@sugarcrm.com>
Date: Thu, 17 Nov 2011 13:10:47 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Matthew Weier O'Phinney <weierophinney@php.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
References: <F2.14.30628.CA275CE4@pb1.pair.com>
In-Reply-To: <F2.14.30628.CA275CE4@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Results of testing ZF against PHP 5.4.0RC1
From: smalyshev@sugarcrm.com (Stas Malyshev)

Hi!

>     I recall from earlier discussions that Stas was in favor of reverting
>     this change -- what's the status at this time? This single change

I was not and still am not - I think if something warrants notice this 
is exactly the case. Conversion of array to string "Array" IMHO makes no 
sense and not useful in any case, so if you code does that it's most 
probably a bug. I understand that some tests were written without 
accounting for this, but frankly in this case I think the right way 
would be to fix the tests. This is not the feature your code should rely 
on (and I think it should have never existed in PHP in the first place) 
and if we shall guarantee compatibility with every bug and bad decision 
we took in the past we won't be able to advance anywhere. I think in 
this case the inconvenience from fixing the tests is outweighed by the 
advantage of promoting better code and exposing hard-to-find bugs.

>   * ob_get_status(true) does not always return an array

According to docs, ob_get_status(true) should return array, so it looks 
like a bug. Please submit a bug report.

>   * ob_get_clean() now raises a notice if no buffer to delete

This is where I say the notice is totally unneeded. Please submit a bug 
for it, it should be silent and return false, just as the docs say.

>   * Redefining a constructor with different arguments now results in E_FATAL
>     Prior to 5.4.0RC1, if a concrete class added arguments to a
>     constructor defined in an abstract class, no warning was raised. This
>     behavior now results in an E_FATAL. I'm ambivalent about this change,
>     however -- the code that raised this for us should be changed
>     anyways.
>
>     However, I'll argue, as others have on the list, that constructors
>     should have the flexibility of redefinition without raising notices
>     or compilation errors.

Here I agree with you, but looks like the majority disagrees. Though I'm 
not sure, frankly, what the point of defining ctor in the abstract class 
is, especially if argument list doesn't stay constant. Maybe clarifying 
this would change the opinion here.

>   * Introduction of the new keyword "callable" means that this can no
>     longer be used for classnames, function names, or method names.
>
>     We had one case where a "callable()" method was defined, and this now
>     breaks; fortunately, it's only in tests, so we can easily fix it with
>     no BC issues on our part. I'll note that I've also used the
>     class|interface name "Callable" in the past on other projects.
>
>     I'm okay with this change, but it needs to be clearly spelled out in
>     the migration docs.

I will update UPGRADING, thanks. The existence of the callable hint is 
documented, but not the fact that it's reserved now.

Thanks for the testing!
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227