Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114721
To: Mel Dafert <mel@dafert.at>, internals@lists.php.net
References: <6D61A2FD-DC80-43A5-81C2-FB19F9CB5078@dafert.at>
Message-ID: <ed8e3d99-5fdc-94c1-0a21-901bf8a3819c@gmx.de>
Date: Fri, 4 Jun 2021 00:07:21 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <6D61A2FD-DC80-43A5-81C2-FB19F9CB5078@dafert.at>
Content-Type: text/plain; charset=utf-8
Content-Language: de-DE
Content-Transfer-Encoding: quoted-printable
Subject: Re: Policy for procedural style in new additions
From: cmbecker69@gmx.de ("Christoph M. Becker")

On 03.06.2021 at 20:28, Mel Dafert wrote:

> After the RFC to add IntlDatePatternGenerator () was accepted, it was br=
ought up that the duplication of
> procedural and OO style was not necessarily/useful anymore.
> This already has some (old) precedent - in 2012, UConverter was added to=
 ext/intl
> (https://wiki.php.net/rfc/uconverter) and in 2014 IntlChar
> (https://wiki.php.net/rfc/intl.char) - both of which only provide a clas=
s, but not the
> procedural API.
> This was also shortly discussed on the mailing list for IntlChar:
> https://externals.io/message/79146#79167 after which the procedural API
> was dropped without much ado.
>
> When I wrote the IntlDatePatternGenerator RFC, I was not aware that the
> procedural API was viewed as deprecated, nor that there had been additio=
ns to
> ext/intl that were purely OO.
> In the thread after its vote, it was also suggested that we add a policy=
 that
> forbids new additions from adding duplicated APIs, and that OO style sho=
uld
> be preferred if possible. I am not sure if I am the best person to write=
 such an RFC,
> but I wanted to bring this to its own thread and provide the context I h=
ave dug up so
> far.
>
> The duplication of the OO and procedural API dates back to the addition =
of the intl
> extension to core. There is some discussion about it in this thread from=
 2008:
> https://externals.io/message/36775
> (ignore the unrelated discussion about PHP6)
> The main argument at this point was that OO in PHP is a new thing, and t=
hat while
> the OO API is objectively better, the procedural API should also be ther=
e to
> lessen the learning curve for existing PHP users that are not yet famili=
ar with OOP.
> I would argue that 13 years later, this argument no longer holds - anyon=
e who
> has used PHP at some point since then most likely has encountered classe=
s.
>
> One open question that still remains is what we do with the already exis=
ting
> procedural API.
> Should it be deprecated? Should it only be soft-deprecated, in that we m=
ention in the
> documentation that the OO style is preferred, but that the procedural AP=
I is
> not planned to be removed?
> Should we just leave the procedural API as-is and live with the fact tha=
t some
> classes have procedural counterparts
> and some don't?
> I would personally lean towards (at least soft-) deprecation just for co=
nsistency,
> but I would like to hear what you would have to say.

I'd take a step at a time, and start with "prohibit introduction of new
dual APIs" only.  (Soft-)deprecation can follow in own RFCs, maybe for
single extensions, or even single (groups of) functions.

=2D-
Christoph M. Becker