Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:129794
Message-ID: <1f4dd9b4-70d0-404a-b1ec-18f3f5b13375@bastelstu.be>
Date: Mon, 19 Jan 2026 22:37:18 +0100
Precedence: list
MIME-Version: 1.0
Subject: Re: [PHP-DEV] [RFC] Context Managers
To: Larry Garfield <larry@garfieldtech.com>,
 php internals <internals@lists.php.net>
References: <a087d9fa-112a-4631-9c84-3efae641e0db@app.fastmail.com>
 <905d9879-70ef-4c87-8578-26519c6d4818@app.fastmail.com>
Content-Language: en-US
In-Reply-To: <905d9879-70ef-4c87-8578-26519c6d4818@app.fastmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
From: tim@bastelstu.be (=?UTF-8?Q?Tim_D=C3=BCsterhus?=)

Hi

On 1/13/26 23:19, Larry Garfield wrote:
> Once those issues are addressed, I think we're nearly able to take CMs to a vote.  (If anyone else wants to weigh in on some other part as well, even if it's just a voice of support/approval, now is the time.)

Something I noticed while reviewing the block scoping RFC: Both RFCs 
come with new OPcodes in the engine.

This can have an impact on extensions that work with OPcodes, for 
example profilers and debuggers. Block scoping already mentioned this in 
the RFC Impact section, but the context manager RFC does not.

For block scoping the two OPcodes are relatively straight-forward 
assignments which should (hopefully) be easy to take into account for a 
debugger. For context managers there seems to be more associated logic 
to set up the scope within the ZEND_INIT_USING OPcode, which might be 
more troublesome for debuggers to correctly reason about when stepping 
through the code (e.g. with the $__RETURN_VALUE meta variable or 
whatever it is called). Perhaps Derick can provide insight here?

Looking at that OPcode I'm also seeing the initialization of the 
`ResourceContextManager` class. In the RFC it is called 
`ResourceContext` and it is non-final there (final in the 
implementation). This is an inconsistency that should be fixed. For that 
one I was also wondering if it is possible to directly initialize it in 
userland (the constructor seems to be public) and if it will then behave 
as expected. I assume the answer is yes to both, but it would be useful 
for the RFC to clarify this.

Best regards
Tim Düsterhus