> On Jun 29, 2024, at 10:57 AM, Michael Morris <[email protected]> wrote:
> On Sat, Jun 29, 2024 at 5:40 AM Mike Schinkel <[email protected]> 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.
After some private time spent documenting my thoughts on modules I realized my thoughts have
diverged from your proposal, so rather than challenge any of your arguments I will just demure and
work on my own contribution.
I discovered the need for a small new feature that would generally be incredibly useful but also
could empower userland to create their own form of modules, and that feature proposal will be much
smaller in scope compared to one for your concept of modules. It may or may not be orthogonal to
the discussion you are leading.
-Mike