Re: Policy for procedural style in new additions

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