Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:124212
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: <CAEUnE0fFfggyvtNGMytWATG7xUrwfjtXp5F0Sk9PvXo-1Rf+_g@mail.gmail.com>
Date: Wed, 3 Jul 2024 23:11:45 -0400
Cc: PHP internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <0E11F373-99DC-496E-9BBC-2F8688B9F66A@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>
To: Michael Morris <tendoaki@gmail.com>
From: mike@newclarity.net (Mike Schinkel)

> On Jul 3, 2024, at 10:31 PM, Michael Morris <tendoaki@gmail.com> =
wrote:
>=20
> On Wed, Jul 3, 2024 at 9:56=E2=80=AFPM Mike Schinkel =
<mike@newclarity.net> wrote:
>=20
> There are ~6300 uses of the keyword `import` on GitHub: =20
>=20
> =
https://github.com/search?q=3Dimport+language%3APHP+symbol%3A%2F%5Eimport%=
24%2F&type=3Dcode
>=20
> That's a lot of BC breakage for some people.
>=20
> No worse than PHP 7's keyword introductions.

True.=20

OTOH, if you don't actually have to break BC for discretionary changes, =
then it would be better not to.

>> Import's behavior is most similar to require_once, but it doesn't =
have to be the same.  Since it is a new entrypoint into the engine the =
way the engine considers the code can be different - whether slightly =
different or radically different is a debate for another time. I'm going =
to stick with only those changes that make sense in the context of =
package links.
>=20
> When you first proposed modules I was understood (wrongly?) that you =
were proposing imports to be a statement that imported into file scope =
and then at the end of loading the file PHP would flush those symbols =
just like how (I think?) JavaScript imports work (I am ignoring the =
complexity closures add to simplify our discussion here.)
>=20
> That was the first iteration, yes.  I am adjusting to the feedback on =
the list.  JavaScript does imports the way it does because of how files =
scope, and how the module system itself scopes, which isn't readily =
retrofitted onto PHP.

I think it *can* be retrofitted to PHP, but that is a different issue =
and I won't derail your discussion to suggest it in this thread.

> Also, at the time I was toying around with the format and had yet to =
hit upon the situation where it could be useful, that being versioned =
files.
> =20
> This sounds like you are saying `import` would (instead?) be dynamic =
like `include*` and `require*` and any symbols loaded with `import` =
would continue their lifetime until the program is finished or the page =
is loaded, depending on how the program is run?
>=20
> Yes, because that is how PHP itself does work under the hood, at least =
for php file includes. How it would go about doing this when resolving =
.so or .dll extensions is another matter.  Does it have to be this way? =
That's the hint I've gotten from the feedback but only a core =
contributor with experience working on the engine could say for sure.
> =20
> I ask because when I was envisioning page scope being added to PHP I =
was also envisioning that PHP could perform more optimizations if the =
new symbols only affected the currently loaded page. If you are =
proposing beyond-page lifetime then that precludes this optimizations =
which is not a deal killer but is a disappointment.
>=20
> Whether the optimizations affect the file on load depends on what's =
being optimized to be honest. There is still an opportunity here.

Where do you see opportunity for optimization =E2=80=94 assuming your =
vision of imports =E2=80=94 that is not already a potential for =
optimization?

> =20
>> Now we have \B\foo();  This makes it relatively easy to have two =
different versions of the package running since in our own code we can =
always reference the foo in the B namespace. But while that allows =
limited package versioning, it doesn't solve the multiple extensions =
wanting to use the new stuff problem outlined above.
>=20
> Consider the following parts of an application:
>=20
> 1. Bespoke app
> 2. "Enterprise Reports" library
> 3. Twig v3 used by "Enterprise Reports"
> 4. "ProductsPro" library
> 5. Twig v4 used by "ProductsPro"
> 6. "PP2ER Connector" library
>=20
> Given your scenario I guess you assume Enterprise Reports would import =
Twig v3 as maybe `ER\Twig` and ProductsPro would import Twig v4 as maybe =
`PP\Twig`, right?
>=20
> Correct.
> =20
>=20
> How does the PP2ER Connector use Twig? =20
>=20
> Depends on which one it wishes to use, \ER\Twig or \PP\Twig
> =20
> Does it create it own `PP2ER\Twig`?  What if the connector needs to =
use the `ER\Twig\Environment` from ProductsPro with the =
`Twig\Loader\FilesystemLoader` from Enterprise Reports where those =
classes have private and protected properties that are simple not =
composable, and especially not across versions.
>=20
> I've never seen cross version mixing like you're describing so I =
didn't take it into account. That said, the extant copies of those =
classes will be variables, and hopefully not global variables.

I have with WordPress plugins.=20

I wish I could say exactly what, where and when, but sadly that =
knowledge was lost to the mists of time.

> Or what it he app itself needs to use the functionality of both in a =
way that requires access to `private` and/or `protected` property values =
or methods across the two versions?
>=20
> That isn't in scope for this discussion. The whole point of private =
and protected scope modifiers is to restrict access by outside code. =
Breaking through that can be done with the Reflection API in some cases, =
but it isn't easy.

I think you misunderstood me.  I was not advocating reaching into =
private or protected.=20

What I was saying is if one indirect dependency used v3 and another =
indirect dependency used v4 then when there is private state the caller =
is still unable to get them to interoperate. =20

Or more simply, indirect dependencies are likely to cause problems when =
interoperability is needed that are not directly in the dependency =
chain.

OTOH, it may be rare enough that we can say "Sucks to be you" if someone =
needs that interoperability. =C2=AF\_(=E3=83=84)_/=C2=AF

>> So we have to call out the version in code, like so.
>>=20
>>   import 'file.php v1.0.0';
>=20
> Where will PHP be able to get the version number in a performant =
manner?
>=20
> A question for another day.

Frankly if your proposal hinges on using version numbers to =
differentiate then I think it is not something you can postpone =
answering.=20

If there is not a good answer then the approach you are exploring is =
moot, at least as far as I can see.

-Mike=