Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:121364
MIME-Version: 1.0
References: <CAH5C8xXfdYEHeoRBi07ecaDQJQ8VxoXMJRiaZ=yw9kTqQaNQ0w@mail.gmail.com>
 <41A81D98-63F2-43AD-BB3C-44CBF8E7BE3C@php.net> <08d4550f-50af-c8f7-222d-572825a57b98@bastelstu.be>
In-Reply-To: <08d4550f-50af-c8f7-222d-572825a57b98@bastelstu.be>
Date: Tue, 17 Oct 2023 22:40:31 +0200
Message-ID: <CAH5C8xVzyXHvcsv-WRu9BDbc6cQr1BmorWhKyJxuxXnzSKKYhA@mail.gmail.com>
To: =?UTF-8?Q?Tim_D=C3=BCsterhus?= <tim@bastelstu.be>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000005c309b0607ef89b1"
Subject: Re: [PHP-DEV] proc_open() resource to opaque object migration
From: kocsismate90@gmail.com (=?UTF-8?B?TcOhdMOpIEtvY3Npcw==?=)

--0000000000005c309b0607ef89b1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=C3=A1t=C3=A9

--0000000000005c309b0607ef89b1--