On Sat, Jun 29, 2024, at 08:32, Michael Morris wrote:
> Not replying to anyone in particular and instead doing a mild reset taking
> into account the discussion that has gone before.
>
> So, I want to import a package. I'll create an index.php file at the root of
> my website and populate it with this.
>
>> <?php
>> import "./src/mymodule";
>
> Now I'll create that directory and run a command `php mod init` in that
> directory. Stealing this from Go, it's fairly straightforward though. Now if
> we look in the directory we will see two files.
>
>> php.mod
>> php.sum
>
> The second file I'll not be touching on but exists to track checksums of
> downloaded packages - Composer does the same with its composer-lock.json file
> which in turn was inspired by node's package-lock.json.
I don't think that is correct... package-lock.json didn't come about until
what, 2016-7ish? with pressure from yarn which did a yarn.lock file. Pretty
sure composer was doing that since the beginning. I remember this being a BIG
reason we switched from npm to yarn when it came out, because dev A would have
different versions of libraries than dev B. Bug hunting was FUN when it was in
a library.
>
> The php.mod file stands in for composer.json, but it isn't a json file. It
> would start something like this:
>
>> namespace mymodule
>> php 10.0
>> registry packagist.org/packages
>>
> We start with three directives - the root namespace is presumed to be the
> directory name. If that isn't true this is a text file, change it. PHP min
> version should be straightforward. Registry details where we are going to go
> get code from. Suppose we want to use our own registry but fallback to
> packagist. That would be this:
>
>> namespace mymodule
>> php 10.0
>> registry (
>> github.com/myaccount
>> packagist.org/packages
>> )
>
> Multiple registry entries will be checked for the code in order. Handling
> auth tokens for restricted registries is outside of scope at the moment.
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.
>
> So let's build the module. We'll make a file called hello.phm. The reason
> for phm and not php is so that web SAPIs will not try to parse this code.
> Further they can be configured to not even allow direct https access to these
> files at all.
>
>> import "twig/twig";
>> use \Twig\Loader\ArrayLoader;
>> use \Twig\Environment;
>>
>> $loader = new ArrayLoader([
>> 'index' => 'Hello {{ name }}'
>> ]);
>>
>> $twig = new Environment($loader);
>>
>> export $twig;
>
SAPIs are the programs that parse ALL php code and return it to the server (ie,
nginx, apache, caddy, etc) to be displayed. The SAPI absolutely needs to parse
these files in order to execute them. Servers are designed to display files, so
any server configured today will just output the contents of these files
because it won't be configured to send the request to the SAPI instead. It's
better to suggest moving these files out of the web-root so it's a non-issue.
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?
> As mentioned in previous discussions, modules have their own variable scope.
> Back in our index we need to receive the variable
>
>> <?php
>> import $twig from "./src/mymodule"
>>
>> $twig->render('index', ['name' => 'World']);
>
> If we load index.php in the web browser we should see "Hello World". If we
> look back in the mymodules folder we'll see the php.mod file has been updated
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).
>
>> namespace mymodule
>> php 10.0
>> registry packagist.org/packages
>>
>> imports (
>> twig/twig v3.10.3
>> symfony/deprecation-contracts v2.5 //indirect
>> symfony/polyfill-mbstring v1.3 //indirect
>> symfony/polyfill-php80 v1.22 //indirect
>> )
>
> Note the automatically entered comment that marks the imported dependencies
> of twig. Meanwhile the php.sum file will also be updated with the checksums
> of these packages.
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?
In fact, it is worth pointing out that how would this system work with
polyfills in-general? Polyfills have their uses -- especially for
library/framework code where you don't control the runtime environment. Like
how would someone polyfill mb_string since people will be adding `import
@mbstring` and not `import symfony/polyfill-mbstring`?
>
> So why this instead of composer? Well, a native implementation should be
> faster, but also it might be able to deal with php extensions.
>
>> import "@php_mysqli"
>>
> The @ marks that the extension is either a .so or .dll library, as I'll
> hazard a guess that the resolution mechanic will be radically different from
> the php language modules themselves - if it is possible at all. If it can be
> done it will make working with packages that require extensions a hell of a
> lot easier since it will no longer be necessary to monkey the php.ini file to
> include them. At a minimum the parser needs to know that the import will not
> be in the registry and instead it should look to the extensions directory,
> hence the lead @. Speaking of, having the extension directory location be a
> directive of php.mod makes sense here. Each module can have its own
> extension directory, but if this is kept within the project instead of
> globally then web SAPIs definitely need to stay out of those directories.
So ... if we want to round, we have to use `import @math` and then we can call
the global round() function? 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.
>
> Final thing to touch on is how the module namespaces behave. The export
> statement is used to call out what is leaving the module - everything else is
> private to that module.
>
>> class A {} // private
>> export class B {} // public
>>
> All the files of the package effectively have the same starting namespace -
> whatever was declared in php.mod. So it isn't necessary to repeat the
> namespace on each file of the package. If a namespace is given, it will be a
> sub-namespace
>
>> namespace tests;
>>
>> export function foo() {}
>>
> Then in the importing file
>
>> import "./src/mymodule"
>> use \mymodule\tests\foo
>>
>>
> Notice here that if there is no from clause everything in the module grafts
> onto the symbol table. Subsequent file loads need only use the use
> statement. Exported variables however must be explicitly pulled because the
> variable symbol table isn't affected by namespaces (if I recall correctly,
> call me an idiot if I'm wrong).
>
> The from clause is useful for permanently aliasing - if something is imported
> under an alias it will remain under that alias. Continuing the prior example
>
>> import tests\foo as boo from "./src/mymodule";
>>
>> boo()
>>
> That's enough to chew on I think.
— Rob
