Re: proc_open() resource to opaque object migration
| From: | Derick Rethans | Date: | Thu, 28 Sep 2023 21:21:49 +0000 |
| Subject: | Re: proc_open() resource to opaque object migration | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-121166@lists.php.net to get a copy of this message | ||
On 28 September 2023 21:19:47 BST, "Máté Kocsis" <kocsismate90@gmail.com> wrote:
>Hi Everyone,
>
>I'm writing in connection with a question coming up lately during the
>"resource to opaque object migration" project (
>https://github.com/php/php-tasks/issues/6) which we have been
>working on
>for quite a long while.
>
>During the review of my PR migrating the resource returned by proc_open()
>to an object (https://github.com/php/php-src/pull/12098), it quickly became
>evident that there was no consensus about the new class name, since the
>originally proposed "Process" name has a non-negligible BC break likelihood.
>
>That's why we should find the best class name in accordance with Nikita's
>namespace naming convention RFC (
>https://wiki.php.net/rfc/namespaces_in_bundled_extensions). Even
>though my
>PR currently implements "Standard\Process", this name is not a good
>candidate according to the policy:
>
>Because these extensions combine a lot of unrelated or only tangentially
>> related functionality, symbols should not be namespaced under the Core,
>> Standard or Spl namespaces. Instead, these extensions should be considered
>> as a collection of different components, and should be namespaced according
>> to these.
>
>
>Does anyone have a good suggestion?
>
>Thanks,
>Máté
Yes, lacking evidence that the name is actually being used: Process
PHP "owns" the top level namespace. This has been documented for decades, too.
cheers
Derick