Send a blank email to [email protected] to get a copy of this message
On Thu, Jun 27, 2024 at 2:11 PM Deleu <[email protected]> wrote:
> Who would build it is an extremely key aspect of making changes to PHP.> Ideas are hard enough to survive the RFC process when there's already an> implementation. Finding a sponsor to work on this would be the first step..>
Agreed.
>> Given that ini settings are frowned upon nowadays, I think having a `<?php> declare(modules=1);` for the initial file might make the idea more likely> to pass a vote? Or maybe I'd even try to go one step further and say that> whatever file is being executed by SAPI (the first PHP file) could be> interpreted with a dumb lookahead. If the file has import / export syntax,> treat it like PHP Module, otherwise fallback.>
MKS Archive already pointed out that even this is unecessary. Just let the
landing file import the modules, even if that means it's a one line file.
>> I'm not familiar enough with Javascript / Typescript ecosystem, but I've> only ever seen / used the ability to import using direct filepath.>
In the clientside up until recently direct filepath was the only way. That
changed with import maps
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/script/type/importmap
NodeJS has been doing something similar serverside for much longer with
CommonJS requires, which predate by a good 5 years the ES6 mechanism. As a
serverside language it now has to juggle both.
The resolution path I sketched out is based on how NodeJS works. Can that
be improved upon? Likely - it is confusing
> The fact there's weird behaviors as result of trying to import a file and> suddenly a file all the way from include_paths or php_modules seems> like a no-go to me. I'd favor using only simple file path navigation and if> the file doesn't exist, error.>> Perhaps if the idea gains merit, Composer could offer something similar to> Vite where we can create an alias to a specific folder and then import> things like from '@package/path/to/file.>
Composer would need a massive rewrite to be a part of this since it
currently requires the file once it determines it should do so. If we do a
system where import causes the parser to act differently then that alone
means imports can't be dealt with in the same manner as other autoloads.
>>>> This will of course require a package manager similar to composer to>> become part of core. However, composer will not be eclipsed as the import>> package manager (phppm?) is only concerned with user modules. These modules>> must explicitly export any symbols being fetched from them, whereas>> composer will continue to load files using require.>>>> Imports can also be done against directories>>>> ```>> import foo from "mypackage">> ```>>>> In this case the parser will look for "mypackage/index.php">>>> I'm not fond of this either.>>
There will need to be a way to define the entrypoint php. I think
index.php is reasonable, and if another entry point is desired it can be
called out -> "mypackage/myentry.php"
> ---------------->> Overall, I think PHP has already reached the limit of surviving with only> PSR-4 and Composer. Single class files were a great solution to get us out> of the nightmare of require and import on top of PHP files. But more> than once I have had the desire to declare a couple of interfaces in a> single file, or a handful of Enums, etc. It seems like PHP Modules could> also address the issue with function autoloading and package-level> visibility. I like the idea but I'm a bit skeptical until we have some> buy-in from someone that could actually get this implemented.>
That would be one of the larger hurdles, if not the largest.