Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:65198
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain sugarcrm.com designates 67.192.241.173 as permitted sender)
Message-ID: <510342CD.6020405@sugarcrm.com>
Date: Fri, 25 Jan 2013 18:43:25 -0800
Organization: SugarCRM
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: Clint Priest <cpriest@zerocue.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> <51033962.1030805@zerocue.com>
In-Reply-To: <51033962.1030805@zerocue.com>
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] I think that "Function naming inconsistency" bug deservers
 more attention
From: smalyshev@sugarcrm.com (Stas Malyshev)

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.
-- 
Stanislav Malyshev, Software Architect
SugarCRM: http://www.sugarcrm.com/
(408)454-6900 ext. 227