Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124075
Content-Type: text/plain;
	charset=utf-8
Precedence: bulk
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.120.41.1.8\))
Subject: Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of
 ES6 from JavaScript
In-Reply-To: <CAEUnE0fOfU1tJNKXuBqbSm8jsp7gqe_JY-SiipdUKNztcx0Rog@mail.gmail.com>
Date: Sun, 30 Jun 2024 02:48:31 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <856F4F70-DC81-4098-82DD-5F6D47CDF3F0@newclarity.net>
References: <CAEUnE0fGZ3jFiBG=GyvnhBzH5a0iO4=n75PM=3+6zLAMrumEvA@mail.gmail.com>
 <CADK1yX+E9mvaM_CHJ8tmEx=O70hf8xasbvngh4wvNM8ce8KKGQ@mail.gmail.com>
 <B5DC69B8-E044-47FB-B81C-307E2C19CB66@newclarity.net>
 <1917CF7C-26D8-4DBE-B05C-5AA650AC6C9F@rwec.co.uk>
 <551cd5b0-1c00-4818-a9ca-97f6b7e8c3dc@app.fastmail.com>
 <CAEUnE0fNxSHN4QGfm6ETMVdE5Mcm1AEebmWs7i9xDNgcWnvQvw@mail.gmail.com>
 <39B496F8-062E-4848-9B3B-529BE8D3415A@newclarity.net>
 <CAEUnE0fOfU1tJNKXuBqbSm8jsp7gqe_JY-SiipdUKNztcx0Rog@mail.gmail.com>
To: Michael Morris <tendoaki@gmail.com>
From: mike@newclarity.net (Mike Schinkel)

> On Jun 29, 2024, at 10:57 AM, Michael Morris <tendoaki@gmail.com> =
wrote:
> On Sat, Jun 29, 2024 at 5:40=E2=80=AFAM Mike Schinkel =
<mike@newclarity.net> wrote:
>> However, be aware that in a Go project repo you are likely to have =
only one `go.mod` =E2=80=94 or multiple if you have numerous CLI apps =
being generated =E2=80=94 whereas every directory with Go code is a =
package (which I think is equivalent to what you are calling "module."
> In my examples I have a local developed module being consumed by a =
project (the index.php file). Trying to keep it simple in this early =
sketch out.
> =20
> So I think your use of them here is conflating the two concepts. One =
is a project-wide concept and the other is a "package" concept.
>=20
> I may well be. I'm looking for something that makes sense in PHP.  =
Namespaces, for good or ill, are a part of php, which is why the php.mod =
in my example declares a namespace, not a package.
> =20
> Also, it is problematic to have `php.mod` and `php.sum` because web =
servers would serve them if not carefully configured hence why I went =
with a leading dot, e.g. `.php.module`
>=20
> This is a tree detail. Working on the forest overall right now. Not =
that it's wrong, but leading dots to hide files is a .nix feature that =
doesn't work on Windows (though applications ported from .nix to windows =
often continue to honor the convention).
> =20
> Aside from being familiar per Javascript, what is the argument to =
requiring the import of specific symbols vs just a package import, e.g.:
>=20
> <?php
> import "./src/mymodule"
>=20
> mymodule->twig->render('index', ['name' =3D> 'World']);
>=20
> To me is seems to just add to boilerplate required.  Note that having =
`mymodule` everywhere you reference `twig` makes code a lot more =
self-documenting, especially on line 999 of a PHP file. =F0=9F=99=82
>=20
> PHP's variable table and symbol table are entirely separate for =
historical reasons. Plenty of people on this list can explain how and =
why, but suffice to say namespace declarations have no effect on =
variables, and variables declared outside functions go into the global =
scope - which is a real trainwreck of a place in long lived =
applications. Wordpress, for example, has a FRIGHTENING number of global =
variables, and they aren't namespaced (they are prefixed, but that only =
goes so far).
>=20
> Modules have their own variable scope. They don't affect the global =
scope at all and I don't think they should be able to import globals at =
all with the global keyword, but that sort of thing can be discussed =
later.  They are also going to need their own symbol scope in case one =
module needs to run an older version of a dependency it would otherwise =
share with another module in the same project because there is a BC =
break between the two dependencies.
>=20
> That said, I wonder if incorporating versioning does not make the =
scope of modules too big to complete?
>=20
> In my experience it's best to get a roadmap in place - which is what =
we're doing here - and THEN scope out the roadmap and determine what =
pieces go in over multiple versions
>=20
> I don't think it is wise to intertwine this concept of modules with =
namespaces like that, but I am replied out for the night. :-)
>=20
> I'm not sure we can completely abandon the concept of namespaces so in =
this version of the proposal I incorporated them since, in the initial =
ramble I ignored them.  Where they land is as of yet an open question.

After some private time spent documenting my thoughts on modules I =
realized my thoughts have diverged from your proposal, so rather than =
challenge any of your arguments I will just demure and work on my own =
contribution.=20

I discovered the need for a small new feature that would generally be =
incredibly useful but also could empower userland to create their own =
form of modules, and that feature proposal will be much smaller in scope =
compared to one for your concept of modules.  It may or may not be =
orthogonal to the discussion you are leading.

-Mike