Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124268
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] [PHP-Dev] Versioned Packagers (Iteration IV)
In-Reply-To: <CAEUnE0f4f1_xCyWYZKJF6Y48mPNLUfDWuA65cZAXLgEzcKX0GA@mail.gmail.com>
Date: Sun, 7 Jul 2024 21:18:49 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <90EBFD07-37B9-4DA1-AD4C-38F14BECC014@newclarity.net>
References: <09559430-4477-4516-8D78-6F4071E1AA6C@newclarity.net>
 <0182F3D6-F464-477F-9029-A2D0A8B50C71@koalephant.com>
 <GV1PR01MB10526D0B220ED0AC9D1C17473C2DD2@GV1PR01MB10526.eurprd01.prod.exchangelabs.com>
 <1AFD7AAE-8BEA-460D-88A8-15BB3D30A775@koalephant.com>
 <CAJp_myXHSHD6+76gyOs=d+cfVgwCmpuhKMtYcVBM6b-i3Bf0WQ@mail.gmail.com>
 <CAEUnE0dObGkb+jUZrVhNRg0JHaM5Kt9d93k3p_0D=jX7kxmYAg@mail.gmail.com>
 <e42cd46b-d98b-4567-a854-03ca54d4dbcf@app.fastmail.com>
 <CAEUnE0cQA-QrmDmAjpBm=sXkE58Y4ODbNwPYY=QBJV46Q8nR9g@mail.gmail.com>
 <CAEUnE0eEjsBXmz8AEVG1SKE=i08-9dit1ze1K0mWrdyQt4okqQ@mail.gmail.com>
 <7B633CC7-C768-4852-A4D0-B252A04F7DE1@newclarity.net>
 <CAEUnE0fFfggyvtNGMytWATG7xUrwfjtXp5F0Sk9PvXo-1Rf+_g@mail.gmail.com>
 <0E11F373-99DC-496E-9BBC-2F8688B9F66A@newclarity.net>
 <CAEUnE0fMGzYimJr71VSFr44FQPBzszfd7FbScfwYx794GZMsrQ@mail.gmail.com>
 <4F720A7A-B7DD-4B31-B0C9-6907419B53A5@newclarity.net>
 <CAEUnE0cf2ekFTsQphH8GjzZ4Yds2DXwxS_DT37UZ4reMHg=D+Q@mail.gmail.com>
 <D412D0D3-AD94-4B06-A302-AC7215271367@newclarity.net>
 <CAEUnE0f4f1_xCyWYZKJF6Y48mPNLUfDWuA65cZAXLgEzcKX0GA@mail.gmail.com>
To: Michael Morris <tendoaki@gmail.com>
From: mike@newclarity.net (Mike Schinkel)

> On Jul 6, 2024, at 8:01 PM, Michael Morris <tendoaki@gmail.com> wrote:
>=20
> Some context from where I'm coming from.  I have been working =
exclusively in React, NodeJS and Go up till about a year ago, and in =
Drupal before that - it being 10 years since the last time I looked at =
WordPress. I need work though, and I was offered a job where about =
two-thirds of my workload is a massive WordPress site that has grown =
well outside the scope WordPress does best.  So I've been getting used =
to it again and added some ulcers along the way.

Yes, a university semester could be filled with the dynamics of =
open-source when a project's user base and those overseeing its =
governance diverge. #fwiw

BTW, you don't happen to be working for my last WordPress client, are =
you? =F0=9F=98=B2

> <epiphany>
> ...
> Many (most?) people on PHP Internals view WordPress coding standards =
as bad and some even view addressing WordPress developers needs as bad =
for PHP....
>=20
> I really don't want to get into that crossfire. WordPress is the =
800lb. gorilla of the PHP app world having more server market share that =
is dominant - how dominant depends on who you ask. The most conservative =
estimate I've seen is about half of PHP sites are running WordPress, and =
the most pro-WP quote I saw claimed it has around 80% share.

The reality is it does not matter if you want to or not, by arguing for =
a feature on PHP Internals that is needed more by user-managed apps like =
WordPress than developer-managed apps, you have stepped into said =
crossfire.

You do not get to pick your reality, your reality picks you.

>>   B/ =3D './path/to/B/'
>=20
> It is not clear to me what a trailing slash means, and especially why =
it is needed on the left-hand side?
>=20
> This is taken from the JavaScript importmap specification, but it =
exists to cordon off direct file includes from directory includes. =
Original spec here: =
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/impo=
rtmap
> =20
> And why slash here when namespaces use backslash?
>=20
> Because it's the end of a path and unless you're on Windows =
directories are delimited with /. They aren't the same thing
> =20
> Also, as someone raised on DOS and then Windows only "converting" in =
2009, I still get confused in *nix when to use a trailing slash and when =
to not, so this trailing slash worries me, if only for that reason =
alone.
>=20
> I understand.  Here it's to call out that the key references a =
directory, not a file. The value must explicitly be a directory, not a =
file, and a trailing slash is the way that is done.  Files are not =
*required* to have extensions after all.
>=20
> Using the `@` here feels cryptic, and hard to discover and remember.
>=20
> Perhaps, but this file is meant to be assembled by composer or some =
other automated means - not by hand.  @ as a package operator is used in =
Node.js to mark package namespaces - essentially the vendor of the =
package is marked with @. =20

I can tell your design here have been heavily influenced by your stated =
extensive experience with Node.js. Node.js' conventions probably seem =
second nature to you and thus easy for you to understand.

But for those us not steeped in Node.js, they are rather cryptic. Any =
time language designers chooses cryptic over obvious they place a large =
burden on learners and relatedly also on the experienced to deal with, =
correct and educate learners. For the languages targeting larger user =
bases like PHP =E2=80=94 vs, say Haskell =E2=80=94 the negative impact =
of cryptic can be widespread and costly in time spent and user base =
lost. =20

So even if Node.js made the regrettable decision to choose cryptic over =
obvious I would implore anyone considering additions to PHP to side with =
obvious over cryptic. Even when said additions will often be automated, =
unless they will *always* be automated, such as the OpCache.

What does "obvious" mean here?  Assuming `.ini` files are use, then =
sections names that define usage, not special sigils.

> I think this would be infinitely easier to follow if packages were =
just included in a `[packages]` section.
>=20
> Packages will need to have some special handling though.=20

Which does not preclude a special section for [packages].

> If, as Larry Gafield has stated, the engine cannot be made to maintain =
multiple symbol tables, then the packages must be bound onto the master =
symbol table. =20

I have heard that repeatedly, but I have yet to hear *why*. =20

PHP is just a C program, and clearly a C program can have multiple data =
structures.  Linux had a similar problem with filesystems and thus =
UnionFS was created. I'd really like to know why an equivalent =
architecture cannot be achieved with PHP's symbol table.

(If the reason why PHP "cannot be made to maintain multiple symbol =
tables" has been stated already, I could have easily missed it. If so =
and someone has a link to externals.io with the explanation, it would =
really appreciate that link.)

> But the legacy code in the package itself needs to believe it is where =
it expects to be - on root.  When a Twig file calls to another Twig file =
it calls `use Twig\Class` in some form or another.
>=20
> Monkey patching such as what happens in =
https://packagist.org/packages/brianhenryie/strauss file accomplishes =
this in userland by rewriting the files.  The whole of the namespace =
resolution system is on the fly file renaming, so doing this in the =
engine should be possible.
>=20
>>   ; An import into a package can be done like so
>>   ; Twig will load into \C\Twig and that use will need to be used by =
any code outside the C package.
>>   @C\Twig/ =3D './path/to/Twig/'
>=20
> Your comments also confuse me a bit. =20
>=20
> Is this saying that your hypothetical app =E2=80=94 which you stated =
this `.ini` file is for =E2=80=94 needs to use a package named `C` use =
"definition" is located at './path/to/C/autoload.ini' then it would use =
this syntax, and that in the app its components would be accessed at =
namespace `\C`?
>=20
> Packages can have an ini file, but they are not REQUIRED to have one. =
Otherwise, the existing library of packages will not be loadable because =
they do not have such files. =20

Yes, hopefully that would be obvious to everyone.

> Without the @ operator the library wouldn't load correctly because all =
the files in Twig, parsed normally, will load to \Twig.  The @C\ tells =
PHP to prefix C to every namespace declaration loaded in that directory =
and each use statement. This is a new behavior entirely and needs to be =
carefully considered.

Again, cryptic.=20

Certainly there is more than one way to indicate this required behavior =
besides a cryptic sigil.

> I think that would work well for newer libraries and packages authored =
and used by developers of Developer-managed apps. OTOH I do not think it =
would be sufficient for any existing libraries or frameworks, nor for =
non-professional developers scratching their own itch on a User-managed =
apps and then deciding to publish it for others to use (which happens a =
lot with User-managed apps.)
>=20
> The problem would be that most (all?) of those would not be =
namespace-prefixing Twig but instead using it directly. I believe you =
need an ADDITIONAL `replace` sectionS that allowed an app/website =
developer to indicate that namespace A should instead be replaced in =
`use` statements and direct references with `B\A` for code that exists =
in directory(s) `C` but not in directories `C\D` where `C` and `D` can =
be globs.
> =20
> ...
> [replace]
> Twig[UpdraftPlus] =3D 'Twig_edaf27eb'
> Twig[Elementor] =3D 'Twig_edaf27eb'
>=20
> No, PHP should handle this quietly under the hood without needing the =
autocomplete author to do this whether it is a person or a userland =
program like Composer.=20

I am pretty sure having PHP "handle it quietly under the hood" could =
never be performant enough for real-world production use on =
medium-to-high traffic websites. That is why I proposed  it be prepared =
in advance by the actor that "builds" the app's source code. =20

For developer-managed apps that actor is typically Composer. But for =
user-managed apps that actor is the user-managed app itself, i.e. =
WordPress and the code in its plugin admin page. WordPress would store =
than info in its MySQL database which is why =E2=80=94 for others =
reading this since you already agreed =E2=80=94 `spl_autoload_map()` =
would need to be able to get the map as an array vs. as just a file.

But I may be wrong. However, one thing is certain; if I am correct that =
it could not be done performantly in PHP then it will never get added to =
PHP in that form, even if an RFC were to pass. So there is really only =
one way to know and that is to develop a proof-of-concept, of which the =
relevant part here could be implement in userland PHP.=20

As an side, I have already started piddling with this PoC, but I am not =
sure how far I can or will take it. But I might be open to collaborating =
on it if you are interested.

> Now earlier today I had a thought that shook me.  The entry point of =
the application in this example will likely call this function before =
anything else, just as applications like Drupal call the autoload =
require before anything else.
>=20
> So, why not call the map first? then let the map designate the entry =
point?
>=20
> A HUGE Can of opportunity worms opens. This is also a wild tangent, =
but again this is a brainstorm thread.
>=20
>   ; First this autoload map needs to tell PHP what it is.  A Package, =
or an application.
>   map_type =3D application

Actually, this seems like a pretty obvious next step once one accepts =
the idea of autoload maps. =20

>   ; The Setup files are those which always need to be run before the =
application is
>   ; ready to do anything.  These files will be loaded with NO ACCESS =
to globals or
>   ; or super globals. The engine's state after running these files =
will be op cached and
>   ; each subsequent request starts from here.  This allows the =
considerable setup work
>   ; that applications like Drupal do to be resolved only once and then =
start from that
>   ; cache.

Although I like the architecture of having a file define things =
declaratively where they can easily be processed by tooling =E2=80=94 I =
tried and failed to find a way to standardize wp-config.php =E2=80=94 I =
am not sure how this would empower the OpCache any more than regular =
code loading from index.php?

> This is also the reason why superglobals aren't visible to these files =
- the
>   ; state cannot make decisions about any specific request because =
they'd bleed into
>   ; subsequent requests - a potential security nightmare.
>   ;
>   ; Note the autoloader of this script will be setup in full before =
these files parse.
>   [setup]
>     [] =3D 'path/to/first/setup/file.php'
>     [] =3D 'path/to/second/setup/file.php'

Bikeshedding a bit, I am not sure "setup" is the right word, but as it =
is bikeshedding I will move on.

While I like the idea of a declarative file to empowering tooling, I am =
not sure how introducing such as file into PHP's page load process =
provides enough improvement vs. simply `include()`ing  "setup" php files =
in the first few lines of `index.php`?  I think there would need to be =
more types of things such a file could standardize and improve =
performance for would need to get buy-in and support for such a change.=20=


To figure that out what those types of things might be would IMO =
requiring looking at widely-used PHP apps =E2=80=94 both user and =
developer managed apps =E2=80=94 to see what things could see an actual =
benefit by defining them in a file like this. For example, could a =
database connection be kept alive between page loads on a high-traffic =
site? (I have zero idea if this latter would increase performance or =
even be a good idea, it is just the first thing that came to mind.)

-Mike=