Re: [RFC] Scope

On Wed, Nov 11, 2026, at 10:04 AM, Frode Børli wrote: > Hi Larry, Côme, > > Thanks for pressing on this; I'd rather fix it in the RFC than find it > in the vote. > > One clarification first, because I think it narrows the problem: a scope > only affects the code that runs inside it, and the only one who can run > your function inside a scope is a caller of yours. That caller can > already clear $_GET before calling you and restore it after, or change > the default timezone for the duration of the call. A scope gives them > nothing they could not do today, except that what the inner code changes > cannot leak back out. So "someone created a scope 40 calls up the stack" > has the same blast radius as "someone cleared the superglobals 40 calls > up the stack": a bug in that caller, not a new way for code to run with > state it was not given. > > What that leaves, and what I take from both of you, is that there are > two reasons to create a scope and the RFC only serves one. A server > creates a scope to start a new unit of work, and there starting empty is > right. A test, a plugin host or a sandbox creates a scope to guard the > current state from the inner code, and there the inner code should see > what the creator sees, now and after any later RFC adds to what follows > the scope. I intend to add that second case: a scope that starts as a > copy of its creator's request arrays and current locale and timezone, so > that code which guards inherits, and a later move changes only what > "fresh" means, which concerns the servers. > > Before I write it up I'd like your view on the shape of it. Should > inherit be the default of new Scope(), with the servers asking > explicitly for a fresh one, or the other way around? Is a shallow copy > of the arrays what you'd expect, or should the inherited scope share > them with its creator? And is there anything else in the "missing > ambient state" category that you'd want covered by the same rule? > > Best regards, > Frode Børli Just to make sure we're talking about the same thing, let me offer a more concrete and realistic example. Older frameworks very often had something like this: function show_flash_messages() { if ($_GET['show'] === 1) { foreach ($_SESSION['flash'] ?? [] as $msg) { print "<p>$msg</p>\n"; } $_SESSION['flash'] = []; } } Modern frameworks tend to have additional layers built on top, but they all eventually bottom out to essentially that logic. (OK, the $_GET is a bit contrived for this example, bear with me.) Assuming a request scope created by a persisted process server (Swerve, FrankenPHP, Swoole, etc), it's probably a safe bet that $_GET and $_SESSION have been cloned, reset, or otherwise setup "properly," for some definition of properly. That means this pre-scope-era code continues to work. My concern is when anyone else creates a Scope (whether we think they should or not), and then calls a function chain that ends up calling show_flash_messages(). That person didn't bother to set up $_GET and $_SESSION, because they didn't even realize show_flash_messages() would be called. So now what happens? My point is that it should still continue to work, as close as possible to were there no scopes involved. To me, cloning all ambient state first, and then letting the person setting up the scope decide what to override, seems like the safest default. Simply inheriting and using the creator's values (so that modifying $_GET inside the scope does impact outside the scope) seems unwise to me. That's a great way for changes to leak unexpectedly. And I'm not entirely sure what the use case is for starting a scope "empty", but perhaps that exists. So I would default to a shallow clone of the ambient state, so that changes do not escape but code that relies on the ambient state that isn't scope-aware still works. Whether the other two options have enough of a use case to be opted-in to, I'm not sure. I'll address the "missing ambient state" part in reply to your other email. --Larry Garfield