Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114718
Date: Thu, 03 Jun 2021 20:28:11 +0200
To: internals@lists.php.net
User-Agent: K-9 Mail for Android
Message-ID: <6D61A2FD-DC80-43A5-81C2-FB19F9CB5078@dafert.at>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Policy for procedural style in new additions
From: mel@dafert.at (Mel Dafert)

Hi internals,
After the RFC to add IntlDatePatternGenerator () was accepted, it was brou=
ght up that the duplication of
procedural and OO style was not necessarily/useful anymore=2E
This already has some (old) precedent - in 2012, UConverter was added to e=
xt/intl
(https://wiki=2Ephp=2Enet/rfc/uconverter) and in 2014 IntlChar=20
(https://wiki=2Ephp=2Enet/rfc/intl=2Echar) - both of which only provide a =
class, but not the
procedural API=2E
This was also shortly discussed on the mailing list for IntlChar:=20
https://externals=2Eio/message/79146#79167 after which the procedural API
was dropped without much ado=2E

When I wrote the IntlDatePatternGenerator RFC, I was not aware that the
procedural API was viewed as deprecated, nor that there had been additions=
 to
ext/intl that were purely OO=2E
In the thread after its vote, it was also suggested that we add a policy t=
hat
forbids new additions from adding duplicated APIs, and that OO style shoul=
d
be preferred if possible=2E 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 hav=
e dug up so
far=2E

The duplication of the OO and procedural API dates back to the addition of=
 the intl
extension to core=2E There is some discussion about it in this thread from=
 2008:
https://externals=2Eio/message/36775
(ignore the unrelated discussion about PHP6)
The main argument at this point was that OO in PHP is a new thing, and tha=
t while
the OO API is objectively better, the procedural API should also be there =
to
lessen the learning curve for existing PHP users that are not yet familiar=
 with OOP=2E
I would argue that 13 years later, this argument no longer holds - anyone =
who
has used PHP at some point since then most likely has encountered classes=
=2E

One open question that still remains is what we do with the already existi=
ng
procedural API=2E
Should it be deprecated? Should it only be soft-deprecated, in that we men=
tion in the
documentation that the OO style is preferred, but that the procedural API =
is=20
not planned to be removed?
Should we just leave the procedural API as-is and live with the fact that =
some
classes have procedural counterparts
and some don't?
I would personally lean towards (at least soft-) deprecation just for cons=
istency,
but I would like to hear what you would have to say=2E

Regards,
Mel