Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127343
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 21:41:03 +0300
Message-ID: <CAAwdEzA82y4HbLD+5LZ4zRYfn0kQG_=psujH0FpZzdF3xb1wDA@mail.gmail.com>
Subject: Re: [PHP-DEV] Module or Class Visibility, Season 2
To: Deleu <deleugyn@gmail.com>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000045256063508c72e"
From: drealecs@gmail.com (=?UTF-8?Q?Alexandru_P=C4=83tr=C4=83nescu?=)

--000000000000045256063508c72e
Content-Type: text/plain; charset="UTF-8"

On Tue, May 13, 2025, 18:35 Deleu <deleugyn@gmail.com> wrote:

> Hi!
>
> It's been a few days since I wanted to send this email to internals, but
> real life has been a bit chaotic so I apologize if it comes off as if I
> didn't research the archives enough. I glossed over the Module conversation
> from 10 months ago and the one that recently surfaced and after deeply
> thinking about Rowan's and Larry's comments I wanted to throw this idea
> into the pit.
>
> Lets preface the conversation with the fact that 1) a module system for
> PHP has been discussed for several years and 2) if there was an easy and
> perfect solution it would have been long implemented by now.
>
> If we consider how GitHub, Composer and Docker Hub works, we can pin a
> very important aspect of "namespaces": {entity}/{project}.
>


Hi, thank you for starting this thread.

I have a similar thing, an idea that was sitting on my mind that I want to
put in writing, so I will share it here.

First of all, I want to acknowledge the problems with big projects, big
monoliths that can only have one composer.json and many libraries needed,
that would eventually clash and make upgrades harder than they need to be.

Can we develop the modules concept without linking ourselves to namespaces
or any other new entity?

I think it might be possible, if every symbol that is defined is attached
to a module when it is loaded.
And we can use something like:
```
module(string $name, callable $closure);
```

The $closure is defined in the current module, but is executed in the new
module.
Anything else follows the logic: the functions and methods are executed in
the module where they are defined and associated with. Any new symbols
defined inherit the current module.

When a module is defined by another parent module, a relation will be
created between them and the parent module would get access to the child
module symbols, but not also the other way around.

There is no need to change anything on the libraries code but only on
composer and autoloading. That is the key point for easy adoption.
Composer-related, each installed package will be loaded in their own module.

What is yet to figure out:
 - can we define internal modules, where the child module symbols are
visible only in the parent defining module and not any level up?
 - once a module defined, can the parent - child relation be
redefined/changed/removed?


I apologize if this changes the solution discussion, but I didn't wanted to
start a new thread on the same topic.

-- 
Alex

--000000000000045256063508c72e
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote gmail_quote_contai=
ner"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, May 13, 2025, 18:35 Dele=
u &lt;<a href=3D"mailto:deleugyn@gmail.com">deleugyn@gmail.com</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;bo=
rder-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Hi!</div><=
div><br></div><div>It&#39;s been a few days since I wanted to send this ema=
il to internals, but real life has been a bit chaotic so I apologize if it =
comes off as if I didn&#39;t research the archives enough. I glossed over t=
he Module conversation from 10 months ago and the one that recently surface=
d and after deeply thinking about Rowan&#39;s and Larry&#39;s comments I wa=
nted to throw this idea into the pit.</div><div><br></div><div>Lets preface=
 the conversation with the fact that 1) a module system for PHP has been di=
scussed for several years and 2) if there was an easy and perfect solution =
it would have been long implemented by now.=C2=A0</div><div><br></div><div>=
If we consider how GitHub, Composer and Docker Hub works, we can pin a very=
 important aspect of &quot;namespaces&quot;: {entity}/{project}.</div></div=
></blockquote></div></div><div dir=3D"auto"><br></div><div dir=3D"auto"><br=
></div><div dir=3D"auto">Hi, thank you for starting this thread.</div><div =
dir=3D"auto"><br></div><div dir=3D"auto">I have a similar thing, an idea th=
at was sitting on my mind that I want to put in writing, so I will share it=
 here.</div><div dir=3D"auto"><br></div><div dir=3D"auto">First of all, I w=
ant to acknowledge the problems with big projects, big monoliths that can o=
nly have one composer.json and many libraries needed, that would eventually=
 clash and make upgrades harder than they need to be.</div><div dir=3D"auto=
"><br></div><div dir=3D"auto">Can we develop the modules concept without li=
nking ourselves to namespaces or any other new entity?</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">I think it might be possible, if every symbo=
l that is defined is attached to a module when it is loaded.</div><div dir=
=3D"auto">And we can use something like:</div><div dir=3D"auto">```</div><d=
iv dir=3D"auto">module(string $name, callable $closure);</div><div dir=3D"a=
uto">```</div><div dir=3D"auto"><br></div><div dir=3D"auto">The $closure is=
 defined in the current module, but is executed in the new module.</div><di=
v dir=3D"auto">Anything else follows the logic: the functions and methods a=
re executed in the module where they are defined and associated with. Any n=
ew symbols defined inherit the current module.</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">When a module is defined by another parent module, a=
 relation will be created between them and the parent module would get acce=
ss to the child module symbols, but not also the other way around.</div><di=
v dir=3D"auto"><br></div><div dir=3D"auto">There is no need to change anyth=
ing on the libraries code but only on composer and autoloading. That is the=
 key point for easy adoption.</div><div dir=3D"auto">Composer-related, each=
 installed package will be loaded in their own module.</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">What is yet to figure out:</div><div dir=3D"=
auto">=C2=A0- can we define internal modules, where the child module symbol=
s are visible only in the parent defining module and not any level up?</div=
><div dir=3D"auto">=C2=A0- once a module defined, can the parent - child re=
lation be redefined/changed/removed?</div><div dir=3D"auto"><br></div><div =
dir=3D"auto"><br></div><div dir=3D"auto">I apologize if this changes the so=
lution discussion, but I didn&#39;t wanted to start a new thread on the sam=
e topic.</div><div dir=3D"auto"><br></div><div dir=3D"auto">--=C2=A0</div><=
div dir=3D"auto">Alex</div><div dir=3D"auto"><br></div><div dir=3D"auto"><b=
r></div><div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_container">=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
</blockquote></div></div></div>

--000000000000045256063508c72e--