Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127345
Precedence: bulk
MIME-Version: 1.0
References: <CADK1yXKg1xpneLs3vJ=nUAAGaVuBhqkEMgbBVaYfcBfQL2vkDg@mail.gmail.com>
In-Reply-To: <CADK1yXKg1xpneLs3vJ=nUAAGaVuBhqkEMgbBVaYfcBfQL2vkDg@mail.gmail.com>
Date: Tue, 13 May 2025 14:47:47 -0400
Message-ID: <CAEUnE0enRQ-guK3Rnm5jGYd7053icN4-8pRt+a0kFe3bykpquw@mail.gmail.com>
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
To: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="0000000000001ec1f9063508df47"
From: tendoaki@gmail.com (Michael Morris)

--0000000000001ec1f9063508df47
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, May 13, 2025 at 11:31=E2=80=AFAM Deleu <deleugyn@gmail.com> 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. Fro=
m
> my extremely limited understanding of the engine, I think the easy/natura=
l
> 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 modu=
le
> 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.

--0000000000001ec1f9063508df47
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 13,=
 2025 at 11:31=E2=80=AFAM Deleu &lt;<a href=3D"mailto:deleugyn@gmail.com">d=
eleugyn@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><div>Hi!</div><div><br></div><div>This wo=
uld allow public, private and protected classes in a way that I believe to =
be useful for the large ecosystem that surrounds Composer. From my extremel=
y limited understanding of the engine, I think the easy/natural step would =
be to allow private/protected classes to be <b>received</b>=C2=A0outside it=
s namespace because a type declaration does not trigger autoload. </div></d=
iv></blockquote><div><br></div><div>This has been discussed before - making=
 Namespaces something beyond what they are - a convenience string replace.=
=C2=A0 That is given</div><div><br></div><div>```php</div><div>namespace fo=
o;</div><div>use otherns\boo;</div><div><br></div><div>function bar () {}</=
div><div>bar();</div><div>boo();</div><div>```</div><div>The engine quietly=
 rewrites as</div><div>```php</div><div>function foo\bar () {}</div><div><b=
r></div><div>foo\bar();</div><div>otherns\boo();</div><div>```</div><div><b=
r></div><div>The engine doesn&#39;t store any notion of namespace directly,=
 it&#39;s just a string replace on the symbol table. And if I recall correc=
tly this is also the reason that \ is the namespace operator - the original=
 proposal was for namespaces to have the :: operator, same as static classe=
s, but late in the implementation it was found that there were disambiguati=
on 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&#39;t say for sure.</div><div><br></div><div>Also, a namespace block c=
ould appear anywhere, so if a stubborn programmer really wanted to get acce=
ss to a private or protected block they could put a namespace block into th=
eir own code with the same namespace.=C2=A0</div><div><br></div><div>This a=
lso doesn&#39;t isolate a module with shared dependencies from changes to t=
hose dependencies.=C2=A0 This makes composer libraries impossible to use ef=
fectively in the absence of a mechanism for coordinating those conflicts fr=
om the core.=C2=A0 And for worse, the WP core team doesn&#39;t want to prov=
ide such. And yes, it really isn&#39;t the PHP dev team&#39;s direct respon=
sibility to step in and *directly* fix that problem.=C2=A0 Indirectly perha=
ps? Only if it is a benefit to everyone who uses the language.</div><div><b=
r></div><div>Neither PHP nor JavaScript deal with directories or other file=
 collections. We have to look to Java and its jar files or golang modules f=
or examples of this. And no, the PSR standard of mapping namespaces to dire=
ctories has nothing to do with how the engine itself sees packages, namespa=
ces, or the world. In truth it sees none of these because they don&#39;t ex=
ist in the runtime in any meaningful way that I&#39;m aware of. Phar perhap=
s? I know little of that system beyond the fact is the manner in which comp=
oser and a few other libs are distributed.</div><div><br></div><div>I sense=
, and I could be wrong here, that there is no appetite for moving beyond th=
e one file at a time model. So the system I proposed last go round was stil=
l a one file solution.</div><div><br></div><div>Other ideas I&#39;ve seen k=
icked around - file based privacy. In this schema a file can declare itself=
 private (public is the assumed and Backward compatible default) and then m=
ark exceptions to this as public.=C2=A0 But for this to truly be useful I f=
ear some file structure awareness would be needed and again, at the moment,=
 PHP doesn&#39;t do that.</div><div><br></div><div>A very long time ago I p=
roposed a require into namespace mechanism.=C2=A0 The engine by default att=
aches all incoming namespaces to the root /.=C2=A0 I suggested (because I n=
aively thought require was a function construct, not a statement, and was i=
gnorant of the difference at the time) that &quot;target namespace&quot; co=
uld be the second argument of require and if provided all the symbols estab=
lished by that file become attached to that namespace.=C2=A0 This could onl=
y work if the autoloader correctly dispatched symbols to the correct namesp=
aces, and I don&#39;t have a clue how it could do that.</div><div><br></div=
><div>The need of the plugin community is code that just plugs into the app=
 and doesn&#39;t need to care about what the other applications are doing.=
=C2=A0 This is currently possible only if the plugin provides all of its ow=
n code and if it does use composer libraries, it resorts to monkey-typing t=
o change the names of all the symbols to something prefixed with the plugin=
 name to avoid collisions.=C2=A0 This approach is NOT optimal but it is the=
 only one at present.</div><div><br></div><blockquote class=3D"gmail_quote"=
 style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p=
adding-left:1ex"><div dir=3D"ltr"><div>However, an important question is wh=
ether this is enough groundwork that could lead to optimizations that have =
been discussed when the topic of module is brought up. For instance, if typ=
e-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 symb=
ols of a namespace all at once? I don&#39;t know.</div></div></blockquote><=
div><br></div><div>Doing that would likely involve giving the engine some n=
otion 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=
&#39;t know, not without research.</div><div><br></div><blockquote class=3D=
"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(2=
04,204,204);padding-left:1ex">
</blockquote></div></div>

--0000000000001ec1f9063508df47--