Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:70648
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: <52AE93E9.7070903@cerny-online.com>
Date: Mon, 16 Dec 2013 06:47:21 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: PHP Internals <internals@lists.php.net>
References: <52ABFE84.8010404@cerny-online.com> <CALJZF3i9iV9N4ALdn6+X-tNZhxvsOj0wM2n3D9rA0pXwanrUig@mail.gmail.com>
In-Reply-To: <CALJZF3i9iV9N4ALdn6+X-tNZhxvsOj0wM2n3D9rA0pXwanrUig@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Flexible function naming
From: robert@cerny-online.com (Robert Cerny)

Michael Wallner wrote:
>
> On Dec 14, 2013 7:45 AM, "Robert Cerny" wrote:
> [...]
>
> >> When a PHP code base is growing over time it looks more and more 
> 'diverse', because of inconsistent function and method naming in core 
> PHP and third party libraries. This cannot be changed by any 
> guidelines. The author of a function has the freedom to assign any 
> name. The user of a function needs some flexibility in referring to a 
> function. It should be possible to use 'array_key_exists', 
> 'arrayKeyExists' or 'arraykeyExists'. Because of the performance 
> impact and possible resolution conflicts this language feature needs 
> to be disabled by default.
>
> Oh, I think this is not the best example, but in 5.6 you can achieve 
> that with the new 'use function' feature.
>
That is not what i mean. My proposal reaches much further. In the 
meantime, i realized how to do it with minimal performance impact. Upon 
parsing, PHP would need to add synonyms for function and method names to 
the namespace depending on the configured referral styles. By 
'namespace' i do not mean a declared PHP namespace in the formal sense. 
By default no referral styles are configured. Users can choose between 
'camel case' and 'underscore'. In this case there would be no need to 
normalize function names when looking up a symbol. It would be built-in 
glasses feature, for those who know the emacs mode.
>
> > This is not difficult to implement. It is only necessary to 
> normalize function names: remove all but leading underscores and lower 
> case the result. The likelihood of conflict is very small.
> >
> > This small change would allow coding teams to create a consistent 
> code base based on 'their' guidelines. Motto: "Have it your way!".
>
> No.
>
What is wrong with having a consistent code base all the way, also 
covering legacy code? I consider this a pretty neat language feature.

Robert