Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:56374
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Date: Thu, 17 Nov 2011 16:45:46 -0500
Message-ID: <21.96.30628.A8085CE4@pb1.pair.com>
To: internals@lists.php.net
References: <F2.14.30628.CA275CE4@pb1.pair.com>
 <4EC57857.6030904@sugarcrm.com>
User-Agent: slrn/pre1.0.0-18 (Linux)
Subject: Re: [PHP-DEV] Results of testing ZF against PHP 5.4.0RC1
From: weierophinney@php.net (Matthew Weier O'Phinney)

On 2011-11-17, Stas Malyshev <smalyshev@sugarcrm.com> wrote:
> >     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.

I can live with this.

> >   * 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.

Done: https://bugs.php.net/bug.php?id=60321

> >   * 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.

Done: https://bugs.php.net/bug.php?id=60322

> >   * 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.

Ralph has done this in a separate thread now.

> >   * 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.

Excellent, thanks.

> Thanks for the testing!

Thanks for the release! :)

-- 
Matthew Weier O'Phinney
Project Lead            | matthew@zend.com
Zend Framework          | http://framework.zend.com/
PGP key: http://framework.zend.com/zf-matthew-pgp-key.asc