Re: [PHP-DEV] proc_open() resource to opaque object migration
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é
Re: [PHP-DEV] proc_open() resource to opaque object migration
Hi On 9/28/23 23:21, Derick Rethans wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
Re: [PHP-DEV] proc_open() resource to opaque object migration
On Thu, 28 Sept 2023 at 21:20, Máté Kocsis 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
Re: [PHP-DEV] proc_open() resource to opaque object migration
On 28 September 2023 21:19:47 BST, "Máté Kocsis" 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: https://www.php.net/unsub.php
[PHP-DEV] proc_open() resource to opaque object migration
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é
