Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70670
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain cerny-online.com from 83.220.144.26 cause and error)
SMTP-policy: ok
Message-ID: <52AF4DD3.1090609@cerny-online.com>
Date: Mon, 16 Dec 2013 20:00:35 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: internals@lists.php.net
References: <52ABFE84.8010404@cerny-online.com> <52AF4383.3070406@gmail.com>
In-Reply-To: <52AF4383.3070406@gmail.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Flexible function naming
From: robert@cerny-online.com (Robert Cerny)

Rowan wrote:
> [...]
>
> We all know that PHP's core functions are drastically inconsistent, 
> but you need to be very sure you have a new and simple approach to 
> solving that problem before expecting much enthusiasm for it.
I cannot judge whether my solution is new, but it is for sure simple. 
Somebody with knowledge of the PHP source code can probably solve it 
within a day: when hooking a function into a namespace, calculate the 
synonyms and hook those in as well.
>> It should be possible to use 'array_key_exists', 'arrayKeyExists' or 
>> 'arraykeyExists'.
>
> This looks to me like making the language *more* inconsistent, not 
> less. Why should different projects be able to call the same built-in 
> function by different names?
My emphasis is on consistency *within* a project, not between. I am 
thinking of applications mainly, not libraries.
>
> If you're thinking more of third-party code not having matching coding 
> conventions, then you might be interested in the work of the Framework 
> Interoperability Group [3] who are aiming to agree a set of voluntary 
> standards for just this kind of thing. That doesn't need any changes 
> to the core language, just for framework and library authors to use an 
> agreed set of conventions.
Thanks for pointing that out! Yet, i am interested in a solution that 
also covers legacy code and the core.

Robert