> On Jul 3, 2024, at 10:31 PM, Michael Morris <tendo...@gmail.com> wrote: > > 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 > > That's a lot of BC breakage for some people. > > No worse than PHP 7's keyword introductions.
True. 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. > > 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. 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. > > 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. Where do you see opportunity for optimization — assuming your vision of imports — that is not already a potential for optimization? > >> 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. I have with WordPress plugins. 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? > > 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. 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. 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. ¯\_(ツ)_/¯ >> 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. Frankly if your proposal hinges on using version numbers to differentiate then I think it is not something you can postpone answering. If there is not a good answer then the approach you are exploring is moot, at least as far as I can see. -Mike
