Le 10/06/2026 à 12:23, Rowan Tommins [IMSoP] a écrit :
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.
Creating a namespace doesn't ensure your structures will be internal. In
PHP, there's nothing today that allow it. Creating a "Package" system
that allows internal private structures is not yet on the menu (I have
other ideas for that, in another thread), but starting with the concept
of PHP modules as files starts the path to make sure a PHP package can
be bundled as a list of PHP modules operating with each other, but the
package configuration is the only one that can `export` the public API,
and all the rest of the defined structures are private and only visible
from inside the package.
The goal of modules, with the current problems that it solves, makes it
really straightforward to follow with packages, and therefore, "private
code". (in userland, because it's another thing for the engine and
compiler...).
Such things would allow two similar versions to coexist, and we could
even imagine two PHP packages having the same name: since they have to
be modules, it's not like defining two classes in the same namespaces,
because every module will have an internal hashed prefix, and their own
personal module tree.
Modules solve the very first part of packages, and solve a few issues
with allowing the creation of private code, even though the compromise
is, for now, that such private code is only possible from inside a module.
