Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127356
Feedback-ID: ifab94697:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 14 May 2025 16:40:40 +0200
To: internals@lists.php.net
Message-ID: <faacf442-2151-44a2-994d-ec28af344d78@app.fastmail.com>
In-Reply-To: 
 <CAEUnE0d8QADSYv+OJMEceN4hdJNcNy=-GLvW-ZoNqoi6_2Lhxw@mail.gmail.com>
References: 
 <CADK1yXKg1xpneLs3vJ=nUAAGaVuBhqkEMgbBVaYfcBfQL2vkDg@mail.gmail.com>
 <3ae9a6ea-f135-472b-b2bf-e6cd6ebad299@app.fastmail.com>
 <CAEUnE0d8QADSYv+OJMEceN4hdJNcNy=-GLvW-ZoNqoi6_2Lhxw@mail.gmail.com>
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
Content-Type: multipart/alternative;
 boundary=621add3e83134630864dd491bddac834
From: rob@bottled.codes ("Rob Landers")

--621add3e83134630864dd491bddac834
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

On Wed, May 14, 2025, at 15:24, Michael Morris wrote:
>=20
>=20
> On Wed, May 14, 2025 at 4:08=E2=80=AFAM Rowan Tommins [IMSoP] <imsop.p=
hp@rwec.co.uk> wrote:
>> __
>>=20
>> What Michael Morris is talking about is really a completely different=
 concept - it's more like "containers", in the sense of Docker, Kubernet=
es, etc, where different sections of code can be isolated, and declare c=
lasses with conflicting fully-qualified names. I don't think it's what m=
ost applications and libraries would want "modules" to be; it's probably=
 best thought of as a completely separate feature.
>>=20
>=20
> Well, it's what Go calls "modules". It's confusing because I was being=
 truthful, not snarky, when I said "Ask 10 programmers for the definitio=
n of module and expect 12 answers."  I'm self trained, so I expect to ge=
t my terms wrong from time to time. But I know enough to identify proble=
ms and needs and I've tried to be clear on that.
>=20
> I'm currently reading up on Phar and seeing exactly how suited it woul=
d be as a foundation for a module system. I've also been reading on how =
go approaches things, but go has package management baked into the compi=
ler - PHP outsources this to userland. I'm going to guess that's largely=
 because of lack of staff - PHP has no large backers (leeches like Faceb=
ook that use it heavily and could back it yes, but not backers) and Go h=
as Google.
>=20

Hi Michael,

Since it appears that nested classes probably won't pass by tomorrow (an=
d thus no need to even touch short-syntax classes); I was going to focus=
 on modules next. As I mentioned in that thread, the two are very closel=
y related on a technical level -- it would have only taken 2-3 lines of =
changes to turn it into namespaces-as-modules and another 10 to turn it =
into proper modules (minus syntax support). However, I would implement i=
t very differently knowing what I know today and with this as a goal (vs=
. nested classes). I have zero idea why people voted "no" and the people=
 who expressed their reasons didn't entirely make sense either. So, I su=
spect it was just down to a poorly worded RFC and/or misunderstanding of=
 how it worked. I'll have to revisit it again later.

Sorry for the vent; that's not what this thread is about.

Modules. First of all, I'd be more than happy to help with the implement=
ation if you're up for some collaboration. Personally, here are my requi=
rements I was going into it with:
 1. Impossible name collisions. If you want to name something Foo\Bar in=
 your module and I want to name something Foo\Bar in mine; we should be =
free to do so. Implementing this is straightforward.
 2. Simple. I don't want to rely on a package manager to create modules =
or even use them. I really like the simplicity of "require_once" from ti=
me to time, and I don't want to see that go away. I have some ideas here=
, like `require_module my-module.php`
 3. Easy to optimize. A module should be compiled as a complete unit so =
opcache (or the engine itself) can make full use of the context. There a=
re a lot of optimizations left on the table right now because the engine=
 dynamically compiles one file at a time.
I haven't really even considered syntax too much; but I personally don't=
 want anything new -- or at least, too "out there." I want it to feel li=
ke a natural extension to the language rather than something bolted on.

I suspect there will need to be at least two new user-land elements to t=
his:
 1. a "module loader" that operates similar to the unified class loader =
Gina proposed.
 2. importing modules and aliasing them (as needed).
Would you be interested in collaborating further?

=E2=80=94 Rob
--621add3e83134630864dd491bddac834
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE html><html><head><title></title></head><body><div>On Wed, May =
14, 2025, at 15:24, Michael Morris wrote:</div><blockquote type=3D"cite"=
 id=3D"qt" style=3D""><div dir=3D"ltr"><div dir=3D"ltr"><br></div><div><=
br></div><div class=3D"qt-gmail_quote qt-gmail_quote_container"><div dir=
=3D"ltr" class=3D"qt-gmail_attr">On Wed, May 14, 2025 at 4:08=E2=80=AFAM=
 Rowan Tommins [IMSoP] &lt;<a href=3D"mailto:imsop.php@rwec.co.uk">imsop=
.php@rwec.co.uk</a>&gt; wrote:</div><blockquote class=3D"qt-gmail_quote"=
 style=3D"margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:=
0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rg=
b(204, 204, 204);padding-left:1ex;"><div><u></u><br></div><div><div><br>=
</div><div>What Michael Morris is talking about is really a completely d=
ifferent concept -&nbsp;it's more like "containers", in the sense of Doc=
ker, Kubernetes, etc, where different sections of code can be isolated, =
and declare classes with conflicting fully-qualified names. I don't thin=
k it's what most applications and libraries would want "modules" to be; =
it's probably best thought of as a completely separate feature.</div><di=
v><br></div></div></blockquote><div><br></div><div>Well, it's what Go ca=
lls "modules". It's confusing because I was being truthful, not snarky, =
when I said "Ask 10 programmers for the definition of module and expect =
12 answers."&nbsp; I'm self trained, so I expect to get my terms wrong f=
rom time to time. But I know enough to identify problems and needs and I=
've tried to be clear on that.</div><div><br></div><div>I'm currently re=
ading up on Phar and seeing exactly how suited it would be as a foundati=
on for a module system. I've also been reading on how go approaches thin=
gs, but go has package management baked into the compiler - PHP outsourc=
es this to userland. I'm going to guess that's largely because of lack o=
f staff - PHP has no large backers (leeches&nbsp;like Facebook that use =
it heavily and could back it yes, but not backers) and Go has Google.</d=
iv><div><br></div></div></div></blockquote><div><br></div><div>Hi Michae=
l,</div><div><br></div><div>Since it appears that nested classes probabl=
y won't pass by tomorrow (and thus no need to even touch short-syntax cl=
asses); I was going to focus on modules next. As I mentioned in that thr=
ead, the two are very closely related on a technical level -- it would h=
ave only taken 2-3 lines of changes to turn it into namespaces-as-module=
s and another 10 to turn it into proper modules (minus syntax support). =
However, I would implement it very differently knowing what I know today=
 and with this as a goal (vs. nested classes). I have zero idea why peop=
le voted "no" and the people who expressed their reasons didn't entirely=
 make sense either. So, I suspect it was just down to a poorly worded RF=
C and/or misunderstanding of how it worked. I'll have to revisit it agai=
n later.</div><div><br></div><div>Sorry for the vent; that's not what th=
is thread is about.</div><div><br></div><div>Modules. First of all, I'd =
be more than happy to help with the implementation if you're up for some=
 collaboration. Personally, here are my requirements I was going into it=
 with:<br></div><ol><li>Impossible name collisions. If you want to name =
something Foo\Bar in your module and I want to name something Foo\Bar in=
 mine; we should be free to do so. Implementing this is straightforward.=
</li><li>Simple. I don't want to rely on a package manager to create mod=
ules or even use them. I really like the simplicity of "require_once" fr=
om time to time, and I don't want to see that go away. I have some ideas=
 here, like `require_module my-module.php`</li><li>Easy to optimize. A m=
odule should be compiled as a complete unit so opcache (or the engine it=
self) can make full use of the context. There are a lot of optimizations=
 left on the table right now because the engine dynamically compiles one=
 file at a time.</li></ol><div>I haven't really even considered syntax t=
oo much; but I personally don't want anything new -- or at least, too "o=
ut there." I want it to feel like a natural extension to the language ra=
ther than something bolted on.</div><div><br></div><div>I suspect there =
will need to be at least two new user-land elements to this:</div><ol><l=
i>a "module loader" that operates similar to the unified class loader Gi=
na proposed.</li><li>importing modules and aliasing them (as needed).</l=
i></ol><div>Would you be interested in collaborating further?</div><div>=
<br></div><div id=3D"sig121229152">=E2=80=94 Rob</div></body></html>
--621add3e83134630864dd491bddac834--