Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121238
Message-ID: <08d4550f-50af-c8f7-222d-572825a57b98@bastelstu.be>
Date: Thu, 5 Oct 2023 21:18:57 +0200
MIME-Version: 1.0
Content-Language: en-US
To: internals@lists.php.net
References: <CAH5C8xXfdYEHeoRBi07ecaDQJQ8VxoXMJRiaZ=yw9kTqQaNQ0w@mail.gmail.com>
 <41A81D98-63F2-43AD-BB3C-44CBF8E7BE3C@php.net>
In-Reply-To: <41A81D98-63F2-43AD-BB3C-44CBF8E7BE3C@php.net>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [PHP-DEV] proc_open() resource to opaque object migration
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=c3=bcsterhus?=)

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