Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:111298
MIME-Version: 1.0
References: <CAESVnVpr=g7s3LBCx5ff=UBR91EOcjWWJ3v3Bsjca98rCyYijQ@mail.gmail.com>
In-Reply-To: <CAESVnVpr=g7s3LBCx5ff=UBR91EOcjWWJ3v3Bsjca98rCyYijQ@mail.gmail.com>
Date: Mon, 3 Aug 2020 17:09:22 +0200
Message-ID: <CAF+90c9qFVEjUmTHqVGFTxACGBtuhYmtgiz=pV1HWk2r3sqMdg@mail.gmail.com>
To: Sara Golemon <pollita@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000f831a905abfa86c9"
Subject: Re: [PHP-DEV] Resource to Object conversion
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000f831a905abfa86c9
Content-Type: text/plain; charset="UTF-8"

On Mon, Aug 3, 2020 at 5:02 PM Sara Golemon <pollita@php.net> wrote:

> I just learned about https://github.com/php/php-tasks/issues/6
>
> Is it the case that we've agreed as a whole to simply make these
> conversions (as quiet under-the-hood, should only break is_resource() type
> of changes) without need for individual RFCs? Or is a perfunctory RFC and
> vote called for on each conversion?
>

Right, these conversions to "opaque" objects are primarily internal
representation changes that do not affect the API of the extension, modulo
is_resource() checks. In the future, we may wish to add proper
object-oriented APIs to these objects (they are currently maximally locked
down to allow future extension). Those API additions should go through the
RFC process (or at least mailing list discussions) as they tend to be more
nuanced than dumb resource->object conversions.

Nikita

--000000000000f831a905abfa86c9--