Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84305
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.176 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <1FCB68B8-3E55-4B5D-B805-9D92D848A3A1@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>
 <1FCB68B8-3E55-4B5D-B805-9D92D848A3A1@gmail.com>
Date: Thu, 5 Mar 2015 06:27:53 +0900
Message-ID: <CAGa2bXYrsa7t80qo_9YEiU=ZD4k+KESU3Hn+DiJeVvwgFyyjRQ@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113aadc238f19a05107d223b
Subject: Re: [PHP-DEV] Consistent function names
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a113aadc238f19a05107d223b
Content-Type: text/plain; charset=UTF-8

Hi Rowan,

On Wed, Mar 4, 2015 at 6:16 PM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> 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?
>

When I start programming with PHP at 2000, I remember that I was confused
function naming convention a lot. I hope that current new users do not have
such confusions, but they probably feel inconsistent name as issue because
it does not look right. Even if IDEs suggest "right" names, I just feel
wrong.
I guess there are not few people feel same way.

People who prefer Ruby likes it because it's not only have shorthand
notations
but it is predictable in many ways. In PHP7, we finally have
uniform(predictable)
evaluation order! predictable foreach! why not predictable function names?

Since PHP does not have predictable(consistent) names even for most basic
functions, function names are not predictable. It makes harder for new PHP
developers to get used to.

As you mentioned, the changes may cause more confusions in short term.
I agree with this. Change causes confusions always more or less...
For me, it is a choice whether

 - we'll have naming confusion forever
or
 - we'll fix it even if there are some confusion in short term resolve it
in the long run.


>- 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 agree fully. I wish we have FALSE for wrong number of parameters.
We should try to provide nicer and consistent new APIs.

However, old API will be kept regardless of new APIs because we care
compatibility. We still have "is_writeable()" (This is typo function) alias
for compatibility, for example.

I'll try to modify document system so that it can handle aliases more
nicely. e.g. Do not list aliases in function list, but document them in
referred function. htmlspecialchars() is documented in html_escape()
and make search system find html_escape() by searching "htmlspecialchars".

If this is done, we don't have many aliases listed in manual page.

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.
>

Keeping legacy names is almost the same as keeping "is_writeable()"
for me...
I'll try as much as I can, like adjusting manual and search system, so
that PHP appears to have consistent function names. This would help
people to reconsider.

We cannot remove all issue at once. We are better to adopt incremental
improvement, aren't we?

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a113aadc238f19a05107d223b--