Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71589
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.53 as permitted sender)
Message-ID: <52E5563A.4070701@gmail.com>
Date: Sun, 26 Jan 2014 18:38:50 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXZJoyV+9qN6v8j3+vHexoqDtHR4cZkgdtdc1GpVkDaD9w@mail.gmail.com> <CAGa2bXY4=3UVDVdR=curS96r=pvTrxDYA0wgy+k7X46omtTPgQ@mail.gmail.com> <7E.A3.39789.25841E25@pb1.pair.com> <CAGAGxbb5xTCQaS7=1BPN0pWPz_Z3MqegJkaJFZfg8Eou+zELYA@mail.gmail.com> <12.A5.39789.B7851E25@pb1.pair.com> <52E16E01.7070401@gmail.com> <52E1BDB0.6050406@garfieldtech.com> <CAGa2bXYUg_YfOhbOVJpt+Hr6R5H34wb1h6dzov-sAzxz-fJtEw@mail.gmail.com> <52E40F7E.3050001@gmail.com> <CAGa2bXaEnYfBkWXTMARg4h4+s5QDHMNPHLB9UT9CgNdwDu_-og@mail.gmail.com>
In-Reply-To: <CAGa2bXaEnYfBkWXTMARg4h4+s5QDHMNPHLB9UT9CgNdwDu_-og@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [PHP6] Function name consistency
From: rowan.collins@gmail.com (Rowan Collins)

On 25/01/2014 23:36, Yasuo Ohgaki wrote:
> For example, I've made pg_query() long time ago while there was pg_exec().
> http://jp2.php.net/manual/en/function.pg-query.php
>
> At that time, there wasn't a prepared query. Now we have pg_execute() 
> to execute
> prepared query.
>
> I guess not many people consider this was harmful.

It's certainly true that aliases are not automatically a bad idea. There 
might have been a bit of confusion when it was introduced and people 
thought the functions did different things, but in this case, the old 
function probably wasn't something people typed on a day-to-day basis.

> I suppose most pgsql users are pleased these new names and aliases.

Actually, *most* pgsql users have probably never used half of those 
functions, and the other half are used once or twice in a rarely-edited 
abstraction layer, and if you asked someone how many underscores were in 
the names they would look it up in the manual. These are not the kind of 
functions usually mentioned regarding general consistency of function 
names - the examples given are often widely-used functions like string 
and array utilities.

These are going to be used all over the place in shared code, and 
applications supporting older versions of PHP will need to carry on 
using old names, applications migrating will have to decide if it's 
worth finding and replacing them all, and new applications will have to 
decide if the new names should be adopted as official coding standards, 
based on what other applications the coders are working on.

> Adding aliases for cleanup does not worth the effort now. I agree.
> However, it does for future. IMHO.

The problem is, that there is no neat dividing line between "short term" 
and "long term". One blurs into the other, and different people were 
perceive the pace of change differently. A long overlap with multiple 
names for everything has its costs, and a short overlap with lots of 
breaking changes also has its cost.

Note that the alternative I and others are advocating is not "no 
change", but "radical change" - rather than introducing different names 
for functions that work in exactly the same way, introduce new ways of 
achieving the same thing, with a nicely unified structure. This makes it 
a much easier to decide and announce "we're going to use OO-style 
strings" (or whatever scheme is invented).

> Name collision by adding aliases is not much issue with namespace.

You keep bringing this up, but I for one have never mentioned it as an 
issue with adding aliases. My point is entirely about the value and cost 
of having multiple names with identical meaning.

I mentioned using namespaces (in the technical sense) as a way of 
radically rearranging functions (e.g. array\filter(), 
array\sort\callback\associative() but better thought out than that) but 
that's nothing to do with name collision really.

> Anyone who don't care cleanup, they don't have to care and keep
> using old names.

Don't forget that a language needs to be easy to *read* as well as easy 
to *write* - if one person ignores the new names, but then reads code 
using them, that code is harder for them to understand.

In short:  there may be particular cases where the advantages of adding 
an alias outweigh the disadvantages, but it's by no means automatic, and 
doing it across the whole of PHP is not going to automatically be good 
for the language's future.

Regards,

-- 
Rowan Collins
[IMSoP]