Send a blank email to [email protected] to get a copy of this message
On Sat, Jun 29, 2024 at 3:52 AM Rob Landers <[email protected]> wrote:
> I don't think that is correct...>
Correct or not it's irrelevant trivia.
While this looks good on paper, you're going to have to standardize how
> packages are accessed (API calls, etc) so they can be used in this file, or> literally anyone who wants to add a competing registry will have to create> an RFC to allow accessing their own registry, which is a ton of politics> for something that is strictly technical -- not to mention a bunch of> if-this-registry-do-that type statements scattered throughout the code,> which makes it harder to maintain.>
While this is a fair point, it's a discussion of trees while we are talking
about the forest. At this early stage of sketching out this system what we
are concerned with is how the registry is set and whether multiples can be
set. Once that's hashed out the details of how registries work -
authentication and all that can be contemplated.
> SAPIs are the programs that parse ALL php code and return it to the server> (ie, nginx, apache, caddy, etc) to be displayed.>
I mis-spoke. What I mean is these files cannot be *directly* invoked. A
normal php file must load first, then the phm file, even if the php file is
a mere one liner that imports the module.
> In other news, I'm not a fan of how many times I have to write "twig" just> to get Twig in the current file. The module already registers a namespace,> why can't the use-statement implicitly import the module?>
Because that's not how PHP works? In this pass I took the stance of not
ditching namespaces and instead incorporating them directly into this
module system. In any event, those namespaces will continue to exist
outside the module system for years. The idea of ditching namespaces
within the modules was met with immediate resistance.
>> In real life, my code is going to be in a module/framework and I'm going> to need to render it there. This example of exporting a dependency also> kinda breaks encapsulation principles, and even though it is an example,> things like this end up in documentation of a feature and cause all kinds> of bad practices (like Symfony and anemic objects).>>
I actually thought about that after typing this and as I was going to
sleep. How this should work is the symbols imported by a module are only
visible in that module. If two modules share a dependency the resolution
must allow them to use different versions, especially if they are different
major versions as there might be a BC break in their shared dependency
which is the reason one module uses the older version
> One of the first things I do in a composer.json file is remove polyfills> through the replace key. It's unnecessary, annoys me in my IDE with having> multiple classes of the same name, and hides the fact that I should> probably install an extension for better performance. How do we do that> with this new setup?>
Go has replace directives in go.mod which you're welcome to look into, but
exploring that level of detail is premature.
> In fact, it is worth pointing out that how would this system work with> polyfills in-general?>
Not yet it isn't.
>> So ... if we want to round, we have to use import @math and then we can> call the global round() function?>
No one said anything about removing php.ini extension directives to
globally install extensions.
> Or if we want to use DateTimeImmutable we have to add import @date? That> seems like a step in the wrong direction since most people don't even know> that most (if not all) global library functions come from extensions -- and> virtually nobody knows the name of each extension and what functions they> have. Also, installing extensions is not 100% straightforward as some> environments need to use pecl, some need to use OS package managers.>
I don't understand this contrarian hostility. As you say, the current
system isn't straightforward. I'm proposing something that is
straightforward and your reaction is to go on about how not straightforward
the current system like it is highly relevant to the proposal. It isn't.
What is relevant is this - composer packages that require specific
extensions aren't as portable as those without such requirements as their
incorporation requires jumping through extra hoops. Wouldn't it just be
better if a module could call out its extension dependencies and have PHP
be able to get them installed WITHOUT asking the user to fire up PECL or
modify the php.ini file?