Re: [RFC] Scope

Le mardi 10 novembre 2026, 13:46:42 heure normale d’Europe centrale Frode Børli a écrit : > Nothing is cleared, in this RFC or in a later one. When a piece of state follows the scope, > each scope has its own instance of it. The root scope keeps the process state exactly as it is > today, so code that never creates a scope, which is all code written before this RFC, sees no > change, now or later. > > Code that runs inside a non-root scope is also meant to keep working as it does today. That is > one of the purposes of Scope: legacy code should keep working in a long-running server without being > rewritten. Take vote B: code that calls Locale::setDefault() for user X and later > Locale::getDefault() does so within one request, and both calls happen in the same scope, so it gets > the locale it set. What changes is that a request for user Y, running in another scope, no longer > sees X's locale. From the point of view of the code, nothing changed; it just stopped being > affected by other requests. > > The reason this holds is where scopes are switched. Code does not switch scope while it is > processing one request. Scopes are switched between requests, by the SAPI or the application server, > which is also the party that has the request to put into the new scope. The parallel work a request > starts stays in the request, through fibers, which follow the scope. Larry's legacyLogic() > example creates a scope in the middle of a request and then expects the request's data to still > be there; that is not what run() is for, and I'll make that more explicit in the RFC. > > Each later move is still its own RFC, with its own BC section and vote; the Future Scope list > states the direction, so that servers and frameworks creating scopes know it before they write that > code. What this RFC fixes now is the rule they would all follow: a scope has its own instance of the > state that follows it, and the root keeps what the process has today. I have to say this answer does not resolve my worry. For code that will be written once the RFC is accepted, it will get broken if a future RFC adds things to what follow the scope. I understand that «Each later move is still its own RFC, with its own BC section and vote», but to me that means that nothing will be able to be changed later to follow the scope, as that would be too big of a BC break. Côme

Attachment: [application/pgp-signature] This is a digitally signed message part. signature.asc