Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:130643
Content-Type: multipart/alternative;
 boundary="------------jBoTh6V2m03Bqyeouo0JGbPj"
Message-ID: <cea1929d-44cb-4d60-aae9-2df894add108@gmail.com>
Date: Wed, 15 Apr 2026 18:39:57 +0200
Precedence: list
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: [PHP-DEV] [RFC] Context Managers
Content-Language: fr
To: internals@lists.php.net
References: <a087d9fa-112a-4631-9c84-3efae641e0db@app.fastmail.com>
 <cf17cf19-f41e-4378-9a82-cb7f1a9d7b70@app.fastmail.com>
 <5d96fca3ca5418e6e9e5d8871b26477f@bastelstu.be>
 <7991abf6-9cc8-444e-885c-4f8cd6078fa8@gmail.com>
 <e2ef88cf-8b90-4af8-8a39-beca2b94684e@app.fastmail.com>
In-Reply-To: <e2ef88cf-8b90-4af8-8a39-beca2b94684e@app.fastmail.com>
From: pierstoval@gmail.com (Alex Rock)

This is a multi-part message in MIME format.
--------------jBoTh6V2m03Bqyeouo0JGbPj
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

Le 15/04/2026 à 17:10, Larry Garfield a écrit :
> I think you're missing the point of this construct.  What you're describing is much closer to the recently-declined `let` scoping keyword (https://wiki.php.net/rfc/optin_block_scoping).

Yep, I would have been much more okay with a revised version of the 
`let` scoping keyword, though the implementation also seems quite 
complex too.

> The entire point of context managers is to abstract away and make reusable the try-catch-finally logic.  That logic needs to live somewhere so that it can be reused.  That is what the ContextManager object is for.  It's not a complication; it's the entire purpose of the RFC.
>
> Since you just recently joined the list you would have missed the earlier discussion in this thread of closures.  (Seehttps://externals.io/message/129077).

I have read a few of the messages on externals.io, maybe not everything, 
but your answer indeed makes things a bit clearer. It mostly makes me 
think that this RFC is a bit complex and I don't see /many/ userland 
use-cases that would actually need this.

IMO, it tries to /make some safeguards/ implicit, like closing 
resources. I recognize that it's useful for this case, but does PHP 
really need a new feature this big "just" to close resources 10 
milliseconds earlier in a process that takes 100ms anyway? The benefits 
would only go to projects with huge amount of concurrent calls, which 
are not all of them.


> In short, closures are what people use today for this use case, but they're a PITA because they don't support auto-capture (unless you're using the single-line version).  That makes them less common, because they're a pain to use in this case.  In addition, they do create a new scope, which... is not what we want in this case.  Not creating a new scope is a feature, not a bug.

No auto-capture in closures is IMO an actual *good* thing, because it 
avoids having issues with the current world of JS/TS where auto-capture 
is default, and it brings problems with references. My suggestion with 
the `scoped` keyword also carries auto-capture by design, which makes 
the "capturing system" (shadowing, references, etc.) less intuitive in 
the first place. It's "yet another thing to keep in mind" at first, but 
for legacy apps renovators like me, it's mostly "they haven't kept this 
in mind" debugging hell ^^', but considering there's always worse, it's 
negligible, especially if it's intended to be a new feature.

Still: creating a new scope makes things safer. It creates a new stack 
with its own pointers, and frees it at finish. They are a pain to use 
for now mostly because there's more code to write, it needs to be called 
(or auto-called with `()` after it), and capture must be explicit via 
`use` . The `scoped` keyword proposal automates all this with existing 
PHP features, while the ContextManager adds new features for that, and 
we don't know (yet) the overhead.


Sorry for being this picky :)

--------------jBoTh6V2m03Bqyeouo0JGbPj
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 8bit

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">Le 15/04/2026 à 17:10, Larry Garfield a
      écrit :<br>
    </div>
    <blockquote type="cite"
      cite="mid:e2ef88cf-8b90-4af8-8a39-beca2b94684e@app.fastmail.com">
      <pre wrap="" class="moz-quote-pre">I think you're missing the point of this construct.  What you're describing is much closer to the recently-declined `let` scoping keyword (<a class="moz-txt-link-freetext" href="https://wiki.php.net/rfc/optin_block_scoping">https://wiki.php.net/rfc/optin_block_scoping</a>).</pre>
    </blockquote>
    <p>Yep, I would have been much more okay with a revised version of
      the `let` scoping keyword, though the implementation also seems
      quite complex too.</p>
    <blockquote type="cite"
      cite="mid:e2ef88cf-8b90-4af8-8a39-beca2b94684e@app.fastmail.com">
      <pre wrap="" class="moz-quote-pre">The entire point of context managers is to abstract away and make reusable the try-catch-finally logic.  That logic needs to live somewhere so that it can be reused.  That is what the ContextManager object is for.  It's not a complication; it's the entire purpose of the RFC.

Since you just recently joined the list you would have missed the earlier discussion in this thread of closures.  (See <a class="moz-txt-link-freetext" href="https://externals.io/message/129077">https://externals.io/message/129077</a>).  </pre>
    </blockquote>
    <p>I have read a few of the messages on externals.io, maybe not
      everything, but your answer indeed makes things a bit clearer. It
      mostly makes me think that this RFC is a bit complex and I don't
      see <i>many</i> userland use-cases that would actually need this.</p>
    <p>IMO, it tries to <i>make some safeguards</i> implicit, like
      closing resources. I recognize that it's useful for this case, but
      does PHP really need a new feature this big "just" to close
      resources 10 milliseconds earlier in a process that takes 100ms
      anyway? The benefits would only go to projects with huge amount of
      concurrent calls, which are not all of them.</p>
    <p><br>
    </p>
    <blockquote type="cite"
      cite="mid:e2ef88cf-8b90-4af8-8a39-beca2b94684e@app.fastmail.com">
      <pre wrap="" class="moz-quote-pre">In short, closures are what people use today for this use case, but they're a PITA because they don't support auto-capture (unless you're using the single-line version).  That makes them less common, because they're a pain to use in this case.  In addition, they do create a new scope, which... is not what we want in this case.  Not creating a new scope is a feature, not a bug.  </pre>
    </blockquote>
    <p>No auto-capture in closures is IMO an actual <b>good</b> thing,
      because it avoids having issues with the current world of JS/TS
      where auto-capture is default, and it brings problems with
      references. My suggestion with the <font face="monospace">`scoped`</font>
      keyword also carries auto-capture by design, which makes the
      "capturing system" (shadowing, references, etc.) less intuitive in
      the first place. It's "yet another thing to keep in mind" at
      first, but for legacy apps renovators like me, it's mostly "they
      haven't kept this in mind" debugging hell ^^', but considering
      there's always worse, it's negligible, especially if it's intended
      to be a new feature.</p>
    <p>Still: creating a new scope makes things safer. It creates a new
      stack with its own pointers, and frees it at finish. They are a
      pain to use for now mostly because there's more code to write, it
      needs to be called (or auto-called with <font face="monospace">`()`</font>
      after it), and capture must be explicit via `use` . The `scoped`
      keyword proposal automates all this with existing PHP features,
      while the ContextManager adds new features for that, and we don't
      know (yet) the overhead.</p>
    <p><br>
    </p>
    <p>Sorry for being this picky :)</p>
  </body>
</html>

--------------jBoTh6V2m03Bqyeouo0JGbPj--