> On Jul 3, 2024, at 10:31 PM, Michael Morris <[email protected]> wrote:
>
> On Wed, Jul 3, 2024 at 9:56 PM Mike Schinkel <[email protected]> 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