Re: Versioned Packagers (Iteration IV)

From: Date: Thu, 04 Jul 2024 01:56:51 +0000
Subject: Re: Versioned Packagers (Iteration IV)
References: 1 2 3 4 5 6 7 8 9  Groups: php.internals 
Request: Send a blank email to [email protected] to get a copy of this message
> On Jul 3, 2024, at 8:16 PM, Michael Morris <[email protected]> wrote:
> Can PHP support multiple packages without rewriting the whole engine?  I think so, but it
> isn't trivial, and the side effects need to be cordoned off so that those who need this
> complexity can have it while the beginning and intermediate coders can ignore it just like they
> ignore strict comparison operators and strict typing unless a library they are trying to use foists
> it on them.
> 
> This is why I advocate a new keyword for this - import. 

There are ~6300 uses of the keyword import on GitHub:  

https://github.com/search?q=import+language%3APHP+symbol%3A%2F%5Eimport%24%2F&type=code
<https://github.com/search?q=import+language:PHP+symbol:/^import$/&type=code>

That's a lot of BC breakage for some people.

For this proposal, would one of these not be acceptable instead (assuming that the compiler could
handle import in this way w/o it being a new reserved word)?:

```
include "file.php" as import
use import "file.php"
```

> 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.

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.)

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?

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.

> 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.

Consider the following parts of an application:

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

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?

How does the PP2ER Connector use Twig?  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.

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?

> So we have to call out the version in code, like so.
> 
>   import 'file.php v1.0.0';

Where will PHP be able to get the version number in a performant manner, remembering that the
problem to be solved is dependencies of dependencies so you cannot rely on a strict directory
structure with version numbers unless a non-PSR4 autoloader format is introduced and widely adopted?

Will packages need to ship composer.lock and developers deploy them? Will that be
performant and secure enough?

What about libraries and packages that do not use Composer?  How will WordPress handle this with
plugin dependencies?

-Mike



Thread (128 messages)

« previous php.internals (#124210) next »