Re: proc_open() resource to opaque object migration
| From: | G. P. B. | Date: | Wed, 04 Oct 2023 23:42:35 +0000 |
| Subject: | Re: proc_open() resource to opaque object migration | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-121225@lists.php.net to get a copy of this message | ||
On Thu, 28 Sept 2023 at 21:20, 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?
>
If there needs to be a namespace, we could take inspiration from Python and
use OS\Process,
as everything relating to processes seem to reside in the os module.
Best regards,
George P. Banyard