Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65197
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain zerocue.com designates 67.200.53.250 as permitted sender)
Message-ID: <51033962.1030805@zerocue.com>
Date: Fri, 25 Jan 2013 20:03:14 -0600
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Stas Malyshev <smalyshev@sugarcrm.com>
CC: Seva Lapsha <seva.lapsha@gmail.com>, =?ISO-8859-2?Q?Damian_Tylczy=F1?=
 =?ISO-8859-2?Q?ski?= <turneliusz@gmail.com>, 
 "internals@lists.php.net" <internals@lists.php.net>
References: <CAGsPR66hpGfvtZQw9A_-Jc-jqEdhWkbq8km1GYZ0K9Ycx9Vn1w@mail.gmail.com> <5102D1DB.9060305@sugarcrm.com> <CAOtCo3qM5oQu4wpn_zhVpyPFDVemxKfBOmB2Qp7dKhUyoot2bw@mail.gmail.com> <51032B3C.7040608@sugarcrm.com>
In-Reply-To: <51032B3C.7040608@sugarcrm.com>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers
 more attention
From: cpriest@zerocue.com (Clint Priest)


On 1/25/2013 7:02 PM, Stas Malyshev wrote:
> Hi!
>
>> Well, how about renaming the functions, create aliases for BC and throw
>> E_DEPRECATED or E_STRICT on their usage? And write a PEAR script bundled
>> with the distribution to migrate to the new convention?
> Well, the problem with these things is this: suppose you have testing
> suite that verifies your code. What you do with E_DEPRECATED? You can
> treat them as failure, and that means in hypothetical PHP 6 release you
> code is broken, and you can't release it until you fixed it - so that
> means for you the effect it as if the function was effectively removed.
> On the other hand, you can ignore it - and then when these functions are
> removed, you get all your code broken, and while it is not removed, it's
> like we didn't do anything.
>
Depending on just what is going to change, a simple script people can 
run to scan their code and spit out a diff of recommended changes they 
can simply review and approve of could be pretty painless.

Then again you probably have people that would be subject to vendor 
updates without the ability to run the script or understand the changes 
it recommends.  May be a small minority though.

Are we talking mostly needle/haystack & haystack/needle type BC changes 
here or other more nefarious things?

Realistically couldn't we just introduce a configuration parameter to 
keep "the inconsistent parameter order," perhaps along with a script to 
suggest the changes needed to bring some code up to speed?

Would be a bit more in the core, for a time, but would allow people to 
transition when they wanted to, without all of the errors...

-- 
-Clint