> On Jul 3, 2024, at 8:16 PM, Michael Morris <tendo...@gmail.com> 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
