Policy for procedural style in new additions

Hi internals, 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. Regards, Mel