On Sat, Jun 29, 2024 at 5:40 AM Mike Schinkel <m...@newclarity.net> wrote:
> 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."
>
> In my examples I have a local developed module being consumed by a project
(the index.php file). Trying to keep it simple in this early sketch out.
> 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.
>
>
I may well be. I'm looking for something that makes sense in PHP.
Namespaces, for good or ill, are a part of php, which is why the php.mod in
my example declares a namespace, not a package.
> 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`
>
>
This is a tree detail. Working on the forest overall right now. Not that
it's wrong, but leading dots to hide files is a .nix feature that doesn't
work on Windows (though applications ported from .nix to windows often
continue to honor the convention).
> 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. 🙂
>
>
PHP's variable table and symbol table are entirely separate for historical
reasons. Plenty of people on this list can explain how and why, but suffice
to say namespace declarations have no effect on variables, and variables
declared outside functions go into the global scope - which is a real
trainwreck of a place in long lived applications. Wordpress, for example,
has a FRIGHTENING number of global variables, and they aren't namespaced
(they are prefixed, but that only goes so far).
Modules have their own variable scope. They don't affect the global scope
at all and I don't think they should be able to import globals at all with
the global keyword, but that sort of thing can be discussed later. They
are also going to need their own symbol scope in case one module needs to
run an older version of a dependency it would otherwise share with another
module in the same project because there is a BC break between the two
dependencies.
>
> That said, I wonder if incorporating versioning does not make the scope of
> modules too big to complete?
>
>
In my experience it's best to get a roadmap in place - which is what we're
doing here - and THEN scope out the roadmap and determine what pieces go in
over multiple versions
> 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. :-)
>
>
>
I'm not sure we can completely abandon the concept of namespaces so in this
version of the proposal I incorporated them since, in the initial ramble I
ignored them. Where they land is as of yet an open question.
