Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65199
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: <5103471D.2010709@zerocue.com>
Date: Fri, 25 Jan 2013 21:01:49 -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: "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> <51033962.1030805@zerocue.com> <510342CD.6020405@sugarcrm.com>
In-Reply-To: <510342CD.6020405@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 8:43 PM, Stas Malyshev wrote:
> Hi!
>
>> 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?
> People think that "introduce a configuration parameter" is a solution to
> almost any BC problem in the engine. It's not true, actually it's the
> opposite - now you have to maintain two code bases, one for one value of
> the parameter and one for another. Now imagine there's 10 such
> parameters, for different things in PHP, and you get 1024 options to
> test you application on. That's why we try to reduce behavior-modifying
> options to a minimum. Config options are for configuration, not for
> changing engine behavior in BC-breaking way. That's one of the reasons
> why magic_* were not a good idea and we had to get rid of them.
>
> And imagine integrating a library that is written with one set of engine
> options into application that expects another set of options. Now
> imagine application that uses a dozen of third-party libraries (in
> current open-source world, it's not too many at all), each of them
> expecting its own set of engine-modifying options. It would very quickly
> become a complete nightmare.
>
> So I think we should try to keep PHP behavior unified and avoid
> behavior-modifying switches as much as possible.
I agree all of that would suck, but would it suck less than the 
alternatives for the most people involved?

-- 
-Clint