On Tue, Apr 1, 2008 at 12:25 AM, Hannes Magnusson
<[EMAIL PROTECTED]> wrote:
>
> On Tue, Apr 1, 2008 at 12:22 AM, Pierre Joye <[EMAIL PROTECTED]> wrote:
>  > On Mon, Mar 31, 2008 at 11:18 PM, Johannes Schlüter <[EMAIL PROTECTED]> 
> wrote:
>  >  > Marcus,
>  >  >
>  >  >
>  >  >  On Mon, 2008-03-31 at 17:14 +0200, Marcus Boerger wrote:
>  >  >  > Hello Derick,
>  >  >  >
>  >  >  >   it is a BUG FIX. Not fixing it means more people will turn it into 
> a
>  >  >  > feature and we will never be able to remove it. Becuase next time you
>  >  >  > will say we cannot remove it in a minor version as by then you 
> accidentally
>  >  >  > rely on it yourself.
>  >  >  >
>  >  >  > We made a mistake! Lets stand up and admit we did. Probably I was 
> involved
>  >  >  > in making that mistake, so sorry. Done.
>  >  >
>  >  >  I have to agree with Derick here we shouldn't add a fatal error within 
> a
>  >  >  bug fix release at such a place. People (hosters...) tend to update
>  >  >  versions without checking all incompatibilities - since you don't 
> expect
>  >  >  them and they want to get security issues fixed.
>  >  >
>  >  >  Yes, the previous behavior was wrong! Yes we shouldn't encourage people
>  >  >  do do that.
>  >  >
>  >  >  I'd propose making it an Warning or something in 5.2 and fixing it in
>  >  >  5.3.
>  >
>  >  E_DEPRECATED  is more appropriate.
>
>  In 5.2? 5.2 doesn't have E_DEPRECATED

Right, then a E_NOTICE will do it as well, but please no warning.

> and this should be fixed in 5.3, not issue a warning that it will be fixed in 
> 5.4 or 6

I don't see a reason for a fatal error in this case.

But if we suddenly agree that fatal errors are common, then please do
it in 5.3 and add a notice only in 5.2.x. It should also be clearly
documented in the OO documentation section.

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to