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