Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84283
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.175 as permitted sender)
User-Agent: K-9 Mail for Android
In-Reply-To: <CAGa2bXbDdS=N=JmPwBa1iorx1aJPuo00EfU7bw31cknAxAfDyQ@mail.gmail.com>
References: <CAGa2bXYa5Lz0JqySVSQ+hGfCW-WxxKWvqFtWaZo=OVf+LLsV8A@mail.gmail.com> <CAEZPtU41xa1yrLPYn_VHx-axOmuM4_KAa00zwPRhpm5ZLSbQ+Q@mail.gmail.com> <CAGa2bXZD1MJojzFu8FwmGKH7gZxpqP7bNUusgQ3YzEpBduCs_g@mail.gmail.com> <CAEZPtU6=KY2tzRE8yw6kEdh4SrVJ3uG81XX5yuu0E_63G1HN6g@mail.gmail.com> <54F4E29D.7080501@garfieldtech.com> <CAGa2bXbph51CUHr_G87FL65hSDfLSDHo14Bnke-vaLu7SmH=ZQ@mail.gmail.com> <54F4E93C.80206@gmail.com> <54F4EBEC.2090702@garfieldtech.com> <CAGa2bXaQ0SgLWdv7WCoo_qyOQH=t2Vi_bwpk7qXZDEUk+7S7ew@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>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
 charset=UTF-8
Date: Wed, 04 Mar 2015 09:16:29 +0000
To: Yasuo Ohgaki <yohgaki@ohgaki.net>
CC: "internals@lists.php.net" <internals@lists.php.net>
Message-ID: <1FCB68B8-3E55-4B5D-B805-9D92D848A3A1@gmail.com>
Subject: Re: [PHP-DEV] Consistent function names
From: rowan.collins@gmail.com (Rowan Collins)

On 4 March 2015 00:46:49 GMT, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote:
>Hi Rowan,
>
>On Wed, Mar 4, 2015 at 7:12 AM, Rowan Collins <rowan.collins@gmail.com>
>wrote:
>
>> You are measuring the wrong cost. The cost of adding new names is to
>> people writing code:
>>
>> - additional confusion for new users about why everything has two
>names
>> and which they should use
>> - extra effort for new developers to learn the new names, even if
>they
>> only read them in other people's code (it slows me down every time I
>see
>> sizeof() and have to remember it's just an alias of count())
>> - awkward decision for project leaders: use the old names for
>familiarity
>> and compatibility with older versions, or the new ones because
>they're
>> arguably better names
>> - if an existing project does choose the new names, the overhead of
>> converting all the existing code, with the risk of bugs introduced by
>> incorrect automation, noise in commit logs, merge conflicts, etc
>> - if a project needs to run on PHP 5, the vigilance required to avoid
>> accidentally using the new names when developing on PHP 7
>>
>> That's not an exhaustive list, and some of these aren't huge costs,
>but
>> collectively they outweigh the benefit of a slightly more consistent
>set of
>> names for things.
>>
>> This is why a more radical change - an OO-style API for scalars and
>basic
>> modules, a fundamentally new set of functions which fulfil a specific
>need,
>> etc - has the potential for acceptance, and this proposal does not.
>The
>> costs are mostly fixed, so we need to increase the benefits to
>outweigh
>> them.
>>
>
>This is fair discussions. We should care these also. I agree these
>costs
>exist
>and shouldn't ignored.
>
>I have different point of views. It's long term view or new user point
>of
>view.
>For me, it outweighs costs you've mentioned.

Several of the costs I listed are for new users, and several will continue indefinitely if we don't remove the old names, and are therefore long term.

Could you be more explicit in the benefits you see? I.e. day to day, how will users lives be better with these new names?


>- PHP has API inconsistency even for most basic APIs like phpversion(),
>htmlspecialchars(), etc
> - Even bundled modules have non standard function names.
> - API parameter ordering is inconsistent.
> - Return type for errors are inconsistent. e.g. Wrong number of param
>returns NULL, while others return FALSE mostly.

For me, argument order and return inconsistency is a much worse problem than name inconsistency. Unfortunately, it's also harder to fix without massive BC breaks. Again, this leads to the conclusion of replacing the entire legacy API, rather than trying to patch over it.

I also think having two names for every function will count as a negative to the kind of people who write these matrixes, and the fact that it was done to fix a previous negative won't change that.

Regards,
-- 
Rowan Collins
[IMSoP]