On Thu, Jun 27, 2024, at 21:23, Michael Morris wrote:
>
> On Thu, Jun 27, 2024 at 1:02 PM MKS Archive <[email protected]> wrote:
>>>
>> Interesting to see this. Serendipitous given the email I sent on the list in reply to
>> Larry.
>>
>> My initial thoughts:
>>
>> 1. I really like the concept of cleaning up issues that BC make impossible to fix by
>> introducing modules.
>
> Thanks. The sticking point is what degree of change should be occurring. PHP isn't as
> behind an 8-ball as JavaScript is since the dev can choose their PHP version and hence deprecation
> works most of the time for getting rid of old stuff. But not always. Changes that are incompatible
> with what came before need a way to do things the old way during transition. Again, see PHP 6 and
> unicode, which snowballed until it was clear that even if PHP 6 had been completed it wouldn't
> be able to run most PHP 5 code.
It’s not just up to the dev, but the libraries we use and whether or not we can easily upgrade (or
remove) them to upgrade the php version.
>
>> 2. No need for autoloaders with modules; I assume this would be obvious, right?
>>
>
> Depends largely on whether modules can include and require to get access to old code. I also
> didn't discuss how they behave - do they share their variables with includes and requires?
I think it would be a mistake to exclude old code and/or prevent templating. Not only are there now
decades old code in some orgs, but how would you write an email sender that sent templated emails,
provide html, generate code, etc? There has to be an output from the code to be useful.
>
>>
>> 3. Not a good idea to use an ini setting; most view them to be problematic.
>> 4. .htaccess îs Apache-only, so a non-starter anyway.
>> 5. The first script should not be a module. If you want that, have a 1 line index.php file
>> do an import.
>
> I love this idea.
>
>
>>
>> 6. Modules should be directories, not .php files. Having each file be a module makes code
>> org really hard.
>
> Yes, but that is how JavaScript currently handles things. It is currently necessary when making
> large packages to have an index.js that exports out the public members of the module. This entry
> point is configurable through the package.json of the module.
I think it’s fine to use js as an inspiration, but it isn’t the only one out there. There is
some precedent to consider directories as modules (go calls them “packages”) and especially in
PHP where namespaces (due to PSR-4 autoloading) typically match directory structures.
For example, I’m still going to go forward with my #[Internal] attribute RFC some time in the next
month or so, which will be namespace based. I have no idea if it will pass, (some people are worried
about it clashing with an RFC like this one) but I think we’d have value in it for years to come
until something like this gets fleshed out. We will see…
>
>> 7. Modules would have a symbol table metadata file generated by IDEs and during deployment.
>
> Node.js uses package.json and the attendant npm to do this sort of prep work. And it's a
> critical part of this since modules can be versioned, and different modules may need to run
> different specific versions of other modules.
Please, please, please do not make a json file a configuration language. You can’t comment in
them, you can’t handle “if php version <9, load this, or if this extension is installed, use
this.”
Maybe that is desirable, but doing things slightly different based on extensions loaded is def a
thing.
>
>> 8. If no metadata file in directory PHP can generate one in memory during first directory
>> access.
>> 9. .php files in modules as identified by metadata file should not be loadable via HTTP(S).
>>
>
> Those are implementation details a little further down the road than we're ready for, I
> think.
Personally, if these are going to have any special syntax, we probably shouldn’t call them .php
files. Maybe .phm?
>
>>
>> 10. Having exports separate from functions and classes seems like it would be problematic.
>
> Again, this is how they work in JavaScript. Not saying that's the best approach, but even
> if problematic it's a solved problem.
the only thing I don’t like about this import/export thing is that it reminds me of the days when
we had to carefully order our require_once directives to make sure files were loaded before they
were used. So, I think it is worth thinking about how loading will work and whether loading can be
dynamic, hoisted out of function calls (like js), how order matters, whether packages can enrich
other packages (like doctrine packages) and if so, how much they can gain access to internal state,
etc. This is very much not “a solved problem.”
>
>> 11. Exports could be implemented as attributes, which could be really elegant.
>> 12. Exports as attributes pairs with the symbol on the line above, and would enable easy
>> aliasing.
>
> Ultimately everything in JavaScript is an object. JavaScript provides a mechanism for handling
> a module file with a single default export, but it supports multiple exports from the same file
> which arrive as an object best approximated in PHP as a static class. I could hash out further, but
> again, I'd like to gauge some interest and very high level feedback.. I'm also interested
> in learning on how other module systems out there do work. I'm picking of JavaScript because
> most of the PHP community has to use it as well for client side scripting and so most of us should
> have at least passing familiarity with it.
In JavaScript, arrays are instances, in php, they are values. This is something to consider if a
module exports an array of exports.
>
>>
>> 13. And finally, when are you starting the RFC? :-)
>
> It's too early for anyone to start at this moment - and while I certainly am willing to
> help I'm not qualified to take the lead on this.
>
> If adopted, this is a massive change, and the results of this conversation won't hit for
> years. Let's take our time. For one, this overarching project will need multiple coordinated
> RFC's, as well as figuring out what to do and also in what order.
— Rob