On Wed, Jul 3, 2024 at 9:56 PM Mike Schinkel <m...@newclarity.net> wrote:
> > 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:/%5Eimport$/&type=code> > > That's a lot of BC breakage for some people. > > No worse than PHP 7's keyword introductions. > 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.)* > 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. 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. > 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? > 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. > 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. > Whether the optimizations affect the file on load depends on what's being optimized to be honest. There is still an opportunity here. > 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? > Correct. > > How does the PP2ER Connector use Twig? > Depends on which one it wishes to use, \ER\Twig or \PP\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. > 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. > > 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? > 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. > > 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? > A question for another day. I'm not going to touch on it yet as I want feedback on the rest of what I've written in this iteration first and, honestly, I want to mull it over in my head a little more. It may be that the code doesn't have the version number but the package declaration file does. There definitely would be advantages to that, but it may still be desirable to have the version called out in the import statement in code.
