Hello, Michael. Thank you very much for your work. It's very interesting.
Let me look at this idea from an architectural perspective. Did I understand correctly from the text that: * Modules control which entities are public and which are not? * During import, we specify which entities we want to bind to which namespace? * Could this solution help with separating Internal and Public classes? In other words, the information about what is public and what is private is part of the module. And the information about how the module is integrated into the project lies outside the module. Could this task be reduced to using `use as`? For example: ```php use \MyClass as MyClass2; ``` This situation is very similar to creating aliases for namespaces, but the difference is that the alias is created not for the code being used, but for the code being loaded. Technically, this is quite possible to implement: 1. We specify that files at a certain path will be loaded into a different namespace. 2. During loading, all namespaces are inserted into the symbol table with the desired alias, as if a person had manually renamed all the modules. But there is one problem here that cannot be solved at all. `PHP` lacks an abstraction over symbols. It doesn’t have a dedicated `Class` or `Namespace` type — strings are used in code for that purpose. And that means any code that tries to load a class using a string constant will break. To solve this, `PHP` would need to introduce a new data type. That’s not a problem, but it does require an `RFC`. In addition, a new `PSR` for packages and autoloading would be needed. You have a great idea, but I think it requires some groundwork in these areas first. P.S. I consider WordPress the best example of what rapid programming can look like — and where it can lead. And I don’t hate it. :) Best Regards, Ed
