On 07-06-2021 12:40, Nikita Popov wrote:
> I think that not adding new procedural mirror APIs is pretty
> uncontroversial at this point. I think one open question is regarding API
> additions to existing classes with a mirror API -- should we keep adding
> procedural functions in that case?
I guess maintaining consistency between the mirror APIs makes sense for
as long as we still have those mirror APIs.
> The more interesting question here is whether we want to deprecate existing
> APIs. From a quick look, these are the extensions that provide procedural
> mirror APIs:
>
> date
> finfo
> intl
> mysqli
> oci8 (only partially)
> xmlwriter
>
> I don't think I'd want to blanket deprecate all of these. I do see value in
> some of the procedural APIs (okay, only date really) or at least historical
> importance (mysqli is a migration target for mysql, which was only
> procedural). I think if we want to deprecate these, it should be on a
> case-by-case basis. For example, I see very little value in the procedural
> intl APIs.
>
> One annoying factor here is that these mirror APIs were often added
> thoughtlessly and have design issues as a result. For example,
> xmlwriter_open_uri() makes sense, but XMLWriter::openUri() should clearly
> have been a static method, not an instance method. Similarly, mysqli_init()
> makes some sense, but mysqli::init() is entirely useless.
Deprecating the procedural APIs where it makes sense sounds like a great
step into the right direction. Historical oddities in the OO APIs could
be dealt with later.
Regards,
Dik Takken
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: https://www.php.net/unsub.php
