> On Jun 29, 2024, at 2:32 AM, Michael Morris <tendo...@gmail.com> 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.
>
> 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 <http://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 <http://github.com/myaccount>
> packagist.org/packages <http://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.
That is very Go-like, as you stated.
However, be aware that in a Go project repo you are likely to have only one
`go.mod` — or multiple if you have numerous CLI apps being generated — whereas
every directory with Go code is a package (which I think is equivalent to what
you are calling "module."
So I think your use of them here is conflating the two concepts. One is a
project-wide concept and the other is a "package" concept.
Maybe you would be better to adopt `module` to mean project and `package` to
mean packaged code as Go has them?
From here on I will refer to directory rather than module or package to avoid
confusion. By directory I will mean what Go calls a "package" and what I think
your original proposal called a "module."
A big difference between Go and PHP is that Go have a compiler that compiles
into an executable before it runs. That is clearly not compatible with PHP, and
why I was proposing that each directory could have a pre-compiled `.php.module`
that could be pre-compiled, or compiled on the fly at first import.
Also, it is problematic to have `php.mod` and `php.sum` because web servers
would serve them if not carefully configured hence why I went with a leading
dot, e.g. `.php.module`
>
> 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;
>
> 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']);
Aside from being familiar per Javascript, what is the argument to requiring the
import of specific symbols vs just a package import, e.g.:
<?php
import "./src/mymodule"
mymodule->twig->render('index', ['name' => 'World']);
To me is seems to just add to boilerplate required. Note that having
`mymodule` everywhere you reference `twig` makes code a lot more
self-documenting, especially on line 999 of a PHP file. 🙂
>
> 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
>
> namespace mymodule
> php 10.0
> registry packagist.org/packages <http://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
> )
Having a `php.sum` file is interesting but again, it should start with a period
if so.
That said, I wonder if incorporating versioning does not make the scope of
modules too big to complete?
> 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.
>
> 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"
I would like this, but I think hosting vendors would block it since extensions
can have C bugs and create vulnerabilities for servers.
I have long thought PHP should kick off a new type of extension using WASM,
which can be sandboxed.
But I digress.
>
> 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.
>
> 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.
I don't think it is wise to intertwine this concept of modules with namespaces
like that, but I am replied out for the night. :-)
-Mike
