Re: Module or Class Visibility, Season 2
On Tue, May 13, 2025 at 11:31 AM Deleu <[email protected]> wrote:
> Hi!
>
> This would allow public, private and protected classes in a way that I
> believe to be useful for the large ecosystem that surrounds Composer. From
> my extremely limited understanding of the engine, I think the easy/natural
> step would be to allow private/protected classes to be *received* outside
> its namespace because a type declaration does not trigger autoload.
>
This has been discussed before - making Namespaces something beyond what
they are - a convenience string replace. That is given
```php
namespace foo;
use otherns\boo;
function bar () {}
bar();
boo();
```
The engine quietly rewrites as
```php
function foo\bar () {}
foo\bar();
otherns\boo();
```
The engine doesn't store any notion of namespace directly, it's just a
string replace on the symbol table. And if I recall correctly this is also
the reason that \ is the namespace operator - the original proposal was for
namespaces to have the :: operator, same as static classes, but late in the
implementation it was found that there were disambiguation problems and the
choice was made to use the \ operator rather than solve those problems. I
assume the problems were judged to be intractable, but I can't say for sure..
Also, a namespace block could appear anywhere, so if a stubborn programmer
really wanted to get access to a private or protected block they could put
a namespace block into their own code with the same namespace.
This also doesn't isolate a module with shared dependencies from changes to
those dependencies. This makes composer libraries impossible to use
effectively in the absence of a mechanism for coordinating those conflicts
from the core. And for worse, the WP core team doesn't want to provide
such. And yes, it really isn't the PHP dev team's direct responsibility to
step in and *directly* fix that problem. Indirectly perhaps? Only if it is
a benefit to everyone who uses the language.
Neither PHP nor JavaScript deal with directories or other file collections.
We have to look to Java and its jar files or golang modules for examples of
this. And no, the PSR standard of mapping namespaces to directories has
nothing to do with how the engine itself sees packages, namespaces, or the
world. In truth it sees none of these because they don't exist in the
runtime in any meaningful way that I'm aware of. Phar perhaps? I know
little of that system beyond the fact is the manner in which composer and a
few other libs are distributed.
I sense, and I could be wrong here, that there is no appetite for moving
beyond the one file at a time model. So the system I proposed last go round
was still a one file solution.
Other ideas I've seen kicked around - file based privacy. In this schema a
file can declare itself private (public is the assumed and Backward
compatible default) and then mark exceptions to this as public. But for
this to truly be useful I fear some file structure awareness would be
needed and again, at the moment, PHP doesn't do that.
A very long time ago I proposed a require into namespace mechanism. The
engine by default attaches all incoming namespaces to the root /. I
suggested (because I naively thought require was a function construct, not
a statement, and was ignorant of the difference at the time) that "target
namespace" could be the second argument of require and if provided all the
symbols established by that file become attached to that namespace. This
could only work if the autoloader correctly dispatched symbols to the
correct namespaces, and I don't have a clue how it could do that.
The need of the plugin community is code that just plugs into the app and
doesn't need to care about what the other applications are doing. This is
currently possible only if the plugin provides all of its own code and if
it does use composer libraries, it resorts to monkey-typing to change the
names of all the symbols to something prefixed with the plugin name to
avoid collisions. This approach is NOT optimal but it is the only one at
present.
However, an important question is whether this is enough groundwork that
> could lead to optimizations that have been discussed when the topic of
> module is brought up. For instance, if type-hint outside the module is
> disallowed, could that make it easier to pack and optimize an entire module
> if we could instruct PHP how to load all symbols of a namespace all at
> once? I don't know.
>
Doing that would likely involve giving the engine some notion of directory,
again as Java does with JAR files, and PHP might do in PHAR files but I
know embarrassingly little about them. Could the existing PHAR structure be
used in some way for a starting point on this? I just don't know, not
without research.
Thread (13 messages)