On 10 June 2026 08:36:44 BST, Alex Rock <[email protected]> wrote: >Le 09/06/2026 à 22:34, Rowan Tommins [IMSoP] a écrit : >> I think this is the crux for me, and why I reacted as I did to your initial >> e-mail. It doesn't look anything like how PHP libraries lay out their code >> today, so migrating to it would involve a complete change of coding style. > >That's the goal here: keep BC at all costs, and make modules transparent in >userland. Change of coding style is opt-in for libraries/frameworks >maintainers that want internal structures whenever they need it.
I'm not talking about BC, or forced migration; I'm talking about the effort required when you *do* want the new facilities. It's not at all clear to me where an existing library would add "export" and "import" keywords in order to mark some classes as internal. It would seem to require completely rearranging the project structure, and rewriting references to all the moved parts. Compare to the work required to use a "namespace visibility" feature: 1. Add a keyword, or an attribute, at the top of each internal class, limiting its use to a certain namespace prefix. 2. There is no step 2. Nothing needs to be moved, or renamed, or accessed differently. That's what I mean by starting with how PHP is used today, and finding ways to enhance it. Rowan Tommins [IMSoP]
