Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:71469
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain garfieldtech.com from 66.111.4.28 cause and error)
Message-ID: <52E1BDB0.6050406@garfieldtech.com>
Date: Thu, 23 Jan 2014 19:11:12 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: 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>
In-Reply-To: <52E16E01.7070401@gmail.com>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: [PHP6] Function name consistency
From: larry@garfieldtech.com (Larry Garfield)

On 1/23/14 1:31 PM, Rowan Collins wrote:

> Therein lies the whole problem with adding more aliases - it just makes
> things more inconsistent, as developers can use (deliberately or
> accidentally) different names for the same function.
>
> I still have to think a moment when I see sizeof() or print, rather than
> count() or echo - let alone having to remember which version of PHP
> introduced which alias so that libraries don't break when deployed to
> older servers.
>
> I think it's far better to have replacements for whole sets of functions
> that are clearly "new and shiny" - be that OO strings and arrays, or
> just namespaces for extensions like mbstring. In fact, a namespace for
> mbstring could allow a much cleaner version of the "override normal
> string functions" system, because you could just "use" the namespace,
> and have functions with overlapping names...
>
> Regards,
> Rowan Collins
> [IMSoP]

Agreed.  Simply aliasing a bunch of functions offers no useful value, 
but does increase confusion.  ("Wait, do I use strcmp() or 
string_compare() on this project?  What version are we on again?  Oh, 
look, this library uses both.  Must have been different devs.  FML.")

If we're going to do anything, be aggressive and far-reaching with it. 
Build a proper language-level OOP design for string/array manipulation.

We have enough functions lying about.  Don't add more.

--Larry Garfield