Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84420
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.43 as permitted sender)
MIME-Version: 1.0
Sender: yohgaki@gmail.com
In-Reply-To: <54FB3175.3000308@luni.fr>
References: <CAGa2bXYa5Lz0JqySVSQ+hGfCW-WxxKWvqFtWaZo=OVf+LLsV8A@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>
 <CAL0xaBF7u2h9A5UnVB+-z6SwDtLOVY_qL7B9UGj7w_Lecwct6A@mail.gmail.com>
 <CAGa2bXa5zER03VrMrtD9aUQ38LK9C_UWU-jbGjzEZUoxbUsSQQ@mail.gmail.com>
 <CAL0xaBFJtxd3gf9H3ToD0-6mugOBFWR50wB_MRnQ0UZsPWF0Fw@mail.gmail.com>
 <CAGa2bXaO=Spn5f6qTY8ZrPE8eJ-qwPMS-+2-FHKAVqAnSKsp+Q@mail.gmail.com>
 <CAEZPtU41SqAf3gV=BY8+g3UNO=k=SyuCER2ch4SNBZ0P4bTbuQ@mail.gmail.com>
 <CAGa2bXaotozdH6mHcXVDPrYDPjw4dxfrFxKkVWrqwPdQBD4tmA@mail.gmail.com> <54FB3175.3000308@luni.fr>
Date: Sun, 8 Mar 2015 08:44:48 +0900
Message-ID: <CAGa2bXZ5ez1Lu2_HRwm_PUQRrTYzO_0bsk3oGbQQ++b_wLzbww@mail.gmail.com>
To: =?UTF-8?Q?Gr=C3=A9gory_Planchat?= <gregory@luni.fr>
Cc: "internals@lists.php.net" <internals@lists.php.net>, Pierre Joye <pierre.php@gmail.com>, 
	Arvids Godjuks <arvids.godjuks@gmail.com>, Rowan Collins <rowan.collins@gmail.com>, 
	Larry Garfield <larry@garfieldtech.com>
Content-Type: multipart/alternative; boundary=001a1142d8cc4ff8860510bb65e6
Subject: Re: [PHP-DEV] Consistent function names
From: yohgaki@ohgaki.net (Yasuo Ohgaki)

--001a1142d8cc4ff8860510bb65e6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi Gregory,

On Sun, Mar 8, 2015 at 2:12 AM, Gr=C3=A9gory Planchat <gregory@luni.fr> wro=
te:

> Le 07/03/2015 02:39, Yasuo Ohgaki a =C3=A9crit :
>
>> We may provide new names and new parameter order in new namespace.
>> The difference is "alias" or "namespace" basically. I don't object to us=
e
>> namespace for it at all. In fact, I would love to have it even if there =
is
>> issue
>> like writing extremely difficult to read code is possible.
>>
>
> Hello all,
>
> I join the thread as a seasoned PHP developer (in user-space), not as a
> PHP core developer. I work since 6 years now for large companies websites
> and I write PHP scripts and programs since 15 years now. I would like to
> bring my brick to this wall.
>
> I follow the thread since a few days now and I have some suggestion which
> can resolve both the functions naming issue for some of you, some others
> suggested to have an object-oriented API and some are fearing massive BC
> breaks.
>
> I read Larry Garfield and Pierre Joye suggesting the idea of an
> object-oriented API, maybe others suggested it already as long as this id=
ea
> is running here since a few years.
>
> I wrote these days the start of a spec of an API, it is far from being
> finished for the scalar types but the array part is almost finished and
> integrates every method documented in the current array API.
>
> https://github.com/gplanchat/php-oop-api
>
> Suggestions are welcome, you can fork and comment. I don't have the
> ambition to rewrite all the PHP core, but just using the existing
> underlying code and applying it a new interface in the userspace.
> Additionally to the current API.
>
> I use the ideas from the [PECL SPL types extension](http://php.net/
> manual/en/book.spl-types.php) and Nikita Popov's [scalar objects
> extension](https://github.com/nikic/scalar_objects).
>
> Those enhancements could be part of one RFC or several, as the amout of
> work can be massive. The essential point is that this refactoring *MUST* =
be
> using only existing code in the core. It *SHOULD* make it appear
> differently to the user. The risk is then lower than a full refactoring. =
It
> is, IMHO, the best compromise for the entire PHP community.
>
> There are several goals and possibilities behind this :
> * Create a consistent and complete API that can satisfy OOP programmers
> and give them a more powerful API
> * Do not create BC breaks on these core types, the ZVAL struct is
> unchanged and the IS_STRING, IS-DOUBLE, ect... are still used as usual
> * Make it possible in a future release (let's say PHP 8, 9 or 10+) to
> deprecate and even remove the old API
> * Build easily encoding-aware strings (binary, ASCII, UTF-8, UTF-16BE,
> UTF-16BE, UTF-32, JIS, Big5, ect...)
>
> Thanks for reading.
>

Nice post indeed! I'll insist to keep procedural API, though :)
We are better to have unified encoding for simplicity. Multibyte string
comparison is
complex, so it's better to have NFC/NFG normalized UTF-8 strings as the
default.
Other encodings can be supported as conversions.

We are better to have consistency between procedural functions and OO
methods
where it is possible. I see a few inconsistencies like "hasKey", "has",
"recursiveWalk".
These names could be adjusted by function and/or method.

This RFC could be made so that it leaves space for consistency. i.e. Do not
touch
variable related functions to have consistent names for both procedural
functions and
OO methods in the future.

Or we may discuss/adjust consistency fully. The change may be introduced
PHP 7.x or even PHP 8. We may take time as long as it takes and have votes
for multiple RFCs that have consistent names/parameters at once.

The latter is better choice. IMO.
My objective with this RFC is to make sure to have consistent procedural
function names "someday" so that PHP will have nice and consistent
procedural
functions forever.

Regards,

--
Yasuo Ohgaki
yohgaki@ohgaki.net

--001a1142d8cc4ff8860510bb65e6--