On 03.06.2021 at 20:28, Mel Dafert wrote: > After the RFC to add IntlDatePatternGenerator () was accepted, it was brought > 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 class, > 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 additions 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 should > 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 have > 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 that > 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. > 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. > > One open question that still remains is what we do with the already existing > procedural API. > Should it be deprecated? Should it only be soft-deprecated, in that we > mention in the > documentation that the OO style is preferred, but that the procedural API is > 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 > consistency, > 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. -- Christoph M. Becker -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
