Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84337
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.176 as permitted sender)
Message-ID: <54F84516.7000303@gmail.com>
Date: Thu, 05 Mar 2015 11:59:18 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: "internals@lists.php.net" <internals@lists.php.net>
References: <CAGa2bXYa5Lz0JqySVSQ+hGfCW-WxxKWvqFtWaZo=OVf+LLsV8A@mail.gmail.com>	<54F4F3FC.6060501@fischer.name>	<CAGa2bXb-d7A3So8e76=p5qqxrZgLK2B_4RKA1OKg0nHZiw9z6A@mail.gmail.com>	<54F4FDFB.8010701@lsces.co.uk>	<CAGa2bXZUvJJVDVj-48qpPuMas12fnDigKGcE-r=TK20Sahyi7w@mail.gmail.com>	<54F5895D.3090002@gmail.com>	<CAGa2bXbuNEcvoeeBhkUUEkiHZJFvJTVX=h_JPTLHpMTtgbCokw@mail.gmail.com>	<554F0C3F-770F-4694-A5AB-FDC54FCCBF00@gmail.com>	<CAGa2bXbDdS=N=JmPwBa1iorx1aJPuo00EfU7bw31cknAxAfDyQ@mail.gmail.com>	<1FCB68B8-3E55-4B5D-B805-9D92D848A3A1@gmail.com>	<CAGa2bXYrsa7t80qo_9YEiU=ZD4k+KESU3Hn+DiJeVvwgFyyjRQ@mail.gmail.com>	<5D8591E2-5AE6-4B4C-AAE0-3D15523410AC@gmail.com>	<CAGa2bXa+RyQLuYe72f2m+j5c+YObfPtaOTeknMRU7p3s+96Seg@mail.gmail.com>	<CEF2AD42-3CE1-489F-8192-D1DC3D8D8698@gmail.com>	<CAGa2bXZDnuE3mKQYD+Sq2=kH=YDXuRQA3o+9wg4v81ZS+h3rLw@mail.gmail.com>	<54F83C4D.1020206@gmail.com> <CAEZPtU6ni038E+b0ziAC1b0w=t3gsmBwMjAui4e0sXd8EgbyXQ@mail.gmail.com>
In-Reply-To: <CAEZPtU6ni038E+b0ziAC1b0w=t3gsmBwMjAui4e0sXd8EgbyXQ@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Consistent function names
From: rowan.collins@gmail.com (Rowan Collins)

Pierre Joye wrote on 05/03/2015 11:49:
> On Thu, Mar 5, 2015 at 3:21 AM, Rowan Collins <rowan.collins@gmail.com> wrote:
>> Yasuo Ohgaki wrote on 05/03/2015 09:24:
>>> I would love to have new OO APIs for variables. I also like to write
>>> procedural
>>> code for simple scripts. Therefore, even if we have new OO APIs, I would
>>> like to
>>> improve/maintain procedural functions and make them not legacy functions.
>>
>> I don't see scalar methods primarily as a way to make PHP more OO (it's just
>> syntax sugar, at the end of the day), but as an opportunity to bring in a
>> new API with real advantages.
>>
>> As Jordi says in the other thread, there are other things you could improve
>> about the array functions beyond making the argument order match the string
>> functions. If you were to sit down and design a new set of array functions
>> (for instance), which were a valuable replacement for the old ones, you
>> wouldn't also need to add dozens of aliases to the old set, because your new
>> set could have a consistent and intuitive naming and behaviour convention.
>>
>> Scalar methods are just one way of designing that new set of functions,  but
>> you could just make a namespace of completely redesigned functions, with
>> deliberately new names to make it obvious which set was being used. At that
>> point, having the aliases you're proposing would be actively harmful,
>> because now users would have to ask (themselves/the manual/Stack Overflow)
>> "is this the new function, or just the new name for the old function?"
> I will say it again a last time, in my opinion only a clean API;
> object-like or real object as long as performance is not affected is
> the only way I could see to actually solve this problem.
>
> Changing the names, argument order (pointless once we will have named
> arguments, btw) and similar solutions are band aids solutions,
> confusing at best, terrible at worst. It is pointless to do it after
> almost two decades for some of them.


For the record, I largely agree. I am open to the possibility of other 
*similarly clean-break* solutions, but have not seen one proposed yet. 
The fact that scalar methods would look completely different from legacy 
functions, including parameter order (because of $this), gives them a 
huge head-start over any other approach I can think of.

If "int", "string", et al acted as real classes, and participated in an 
extendable hierarchy of "value types", that would be even more awesome, 
but entirely incidental to concerns over consistency.

Regards,
-- 
Rowan Collins
[IMSoP]