Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:17248
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <20050712161703.rf2hn68dptcswssw@marina.horde.org>
Date: Tue, 12 Jul 2005 16:17:03 -0400
To: internals@lists.php.net
References: <20050712105234.5dhkvvd6ghcsw8sg@marina.horde.org>
	<Pine.LNX.4.62.0507122051270.16196@localhost>
	<20050712212026.5bd2dbbb.pierre@dotgeek.org> <42D42430.5060001@prohost.org>
In-Reply-To: <42D42430.5060001@prohost.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset=ISO-8859-1;
	format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: 7bit
User-Agent: Internet Messaging Program (IMP) 4.1-cvs
Subject: Re: [PHP-DEV] php 4.4 BC break
From: chuck@horde.org (Chuck Hagenbuch)

Quoting Ilia Alshanetsky <ilia@prohost.org>:

> In this case the "facility" was implementing, poorly might I add a 
> handler for a clearly incorrect behavior. Removing it was not only 
> appropriate but necessary to encourage proper code being written.

I know that other people have other points of view, but I am not 
arguing this. I'm just asking that 4.4 be marked as having a non-BC 
change, because - whether I could have updated my new code or not - 
there's a ton of existing code out there that will never magically 
change to run silently under 4.4.

I've already had people running old major versions of applications 
upgrade to PHP 4.4 because it has "security fixes", and then come 
complaining because suddenly they get a ton of warnings.

Yes, they could turn off warnings. But since the code has always run 
cleanly beforehand, they don't think to do that.

Yes, they could very well ignore a note on php.net about the code 
they're downloading.

But if there *was* a note with the 4.4 release, it would somewhat 
lighten the load on PHP application developers dealing with the change.

-chuck

-- 
"But she goes not abroad in search of monsters to destroy." - John 
Quincy Adams