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é
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
Hi
Yes, lacking evidence that the name is actually being used: Process
PHP "owns" the top level namespace. This has been documented for decades, too.
I agree here. While I'm totally in favor of using namespaces in core, it
should be done somewhat consistently. If the proc_* functions are in the
global namespace, then so should the resource object.
Choosing a less-than-great classname just because it might break
non-namespaced userland code is likely going to cause sadness in the
future, e.g. for folks that need to use it within a type declaration.
Any decision we make now effectively needs to survive for 10+ years.
'Process' is fine. 'Proc' would be consistent with the function prefix.
'ProcessHandle' would also work, but might not be the ideal choice if /
when the resource object gets methods in the future. There is some
precedent with GMP which got a proper contructor, because if was
forgotten to make the constructor private when initially introducing it:
https://github.com/php/php-src/issues/10155
Best regards
Tim Dsüterhus
Hi Tim,
I agree here. While I'm totally in favor of using namespaces in core, it
should be done somewhat consistently. If the proc_* functions are in the
global namespace, then so should the resource object.
While I don't necessarily want to add a dedicated namespace for Process (or
whatever name we settle on), I don't agree with the reasoning: the resource
to
opaque object migration project is just a first step, afterwards, a new
object
oriented API could be added (as you already noted), and later on,
the procedural
one should be deprecated. That's why I think this kind of consistency is
not important
in this case. Please note that many such opaque objects have been added to
namespaces recently (e.g. FTP\Connection, IMAP\Connection,
LDAP\Connection etc.). so we already have some precedent.
I agree with the rest of your answer though. My favourite name is Process
and
I am fine with ProcessHandle as well. The latter name was proposed by
Nicolas in a private conversation.
In my opinion, a straw poll should decide the naming question. I honestly
don't
think that the change needs any more discussion/an RFC, as it doesn't cause
any larger BC break than some of the other resource migrations we performed
since PHP 8.0 -- and there were a lot of them: resources of around 20
extensions
got converted to proper objects among curl, openssl, and pgsql just to
mention some.
I'd argue that at least ext/curl is more widespread than proc_* functions
are.
Regards,
Máté
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