On Fri, Nov 6, 2026, at 3:40 AM, David Maye wrote:
> Hello,
Please remember to bottom post, not top post.
> I agree that `as` seems more coherent than `=>` in PHP. The only time I
> saw `=>` in PHP was with key => value. And in JS it was with `() => {}`
> functions.
>
> I have another question. This mechanism of Context Manager, Is it the
> same as the Ruby `do` blocks? Example with Vagrant Ruby configuration
> file:
>
> ```
> Vagrant.configure("2") do |config|
> config.vm.box = "bento/ubuntu-24.04"
> config.vm.box_version = "202510.26.0"
> end
It's not quite the same. I don't have any Ruby experience, so going based on
https://zetcode.com/ruby/do-keyword/, it can be used in a similar way but it's
not the same mechanism. Ruby (per that page) creates a closure for a do block,
and thus variables go out of scope at the end and get closed implicitly. A
using block in this RFC creates no closure or scope. The body of the using
expression executes in the same function context as the code around it. Also,
the context manager generator itself allows more cleanup than just "unset()" on
the context variable. That happens automatically, which can trigger some
cleanup, but the context manager is able to do a lot more if it wants to.
The model we are building from is Python, basically.
> When you set the example as:
>
> ```
> using (file_for_write('file.txt') => $fp) {
> foreach ($someThing as $value) {
> fwrite($fp, serialize($value));
> }
> };
> // At this point, we're guaranteed that $fp has closed, whether there
> was an error or not.
> ```
>
> It means that the block inside `using` is aware of variables outside of
> it's own scope, right?
Correct. There is no "own scope". As implemented currently, it's just
materializing some generator read logic around the body of the using block.
There is no new function scope created, so the code inside is "in" the function
it's already in, as it always has been.
> I like the idea. I have to admit that at first I was confused because I
> thought that the first example in the RFC post was exactly the same as
> the second example (Error catching included).
You mean in the introduction? They do accomplish the same goal, just with less
code in the context manager version.
> I have another question: according to PHP documentation ("Freeing
> resources"
>
> https://www.php.net/manual/en/language.types.resource.php#:~:text=makes%20no%20sense.-,Freeing%20resources,-%C2%B6):
>
> "Thanks to the reference-counting system being part of the Zend Engine,
> a resource with no more references to it is detected automatically, and
> it is freed by the garbage collector. For this reason, it is rarely
> necessary to free the memory manually."
>
> From what I understand by this text, `fclose()` is optional (but
> recommended according to some Stack Overflow posts). In both cases
> (using or not the using `using`), this acts exactly the same. The only
> difference is that you declare the variable inside the using instead of
> the outside the try/catch block, right? Because even inside the `using`
> function you would need to invoke the `fclose()` function, right?
PHP will automatically close() a resource that goes out of scope, just as it
will garbage collect an object that goes out of scope. However, that is only
true if that is the last reference to that resource/object. If the value had
"escaped" (see the section in the RFC), then the file wouldn't be closed at
that point. Also, even if PHP will cleanup as it goes, it's still good
practice to close a file when you're done with it to minimize race conditions.
A using block takes care of both of those for you. The context manager
generator function is where the fclose() would live, so you don't have to
remember to write it yourself every time.
> Apart from easing the expressiveness of the language, I'm curious of
> what would be other benefits. In the post you express that it provides
> "a way to abstract out common control-flow and
> variable-lifetime-management pattern". What are the ways this function
> may bring such improvements? Are those improvement observed by language
> like Python not already available in PHP by default? I read somewhere
> that PHP tends to be more memory efficient than Python due to the
> processing of the many magic methods and other issues. If so, Is the
> context manager in Python focused on improving the
> variable-lifetime-management due to Python internal issues, and are
> these issues present in PHP?
The examples section includes most of the example cases I could think of off
hand, but I'm sure there are more. Basically, any time you have the use case
of "I want to stick some setup logic at the start of this code, and some
cleanup and error handling logic at the end", a context manager can abstract
that away for you, resulting in reusable logic and in your business logic not
getting confused with the boilerplate error handling.
Think of opening a connection to some remote service and sending a message to
it, but then there's like 10 error cases you need to handle. That's a great
example to factor out into a using block, so you don't need to do all that
error handling each time.
For use in Python, I recommend this video, which lays out a "Pythonic" way of
thinking, and in particular shows how context managers in Python can help
vastly simplify code.
https://www.youtube.com/watch?v=wf-BqAjZb8M
(That's the video that really helped me wrap my head around context managers
and made me want them in PHP.)
As far as performance, there's a huge number of differences between PHP and
Python that impact performance. The engine itself is less efficient, plus yes,
Python relies a lot more heavily on magic callbacks that incur extra overhead
(just as they do in PHP). You can't really pin it down to any one thing.
Context Managers in Python in particular are mainly about managing flow of
control and error handling, not performance, which is the same for this RFC.
The way using is implemented here, that impact is minimal. It adds a generator
invocation and read, and that's about it. So it's not 100% free, but the
overhead is minimal, and comparable to if you were passing a closure to some
ordinary function that did the same sort of wrapping.
--Larry Garfield
