I have no proposal. I'm brainstorming. Please don't step out of this
conversation as it has been enormously helpful.
On Sun, Jun 30, 2024 at 2:48 AM Mike Schinkel <m...@newclarity.net> wrote:
> > On Jun 29, 2024, at 10:57 AM, Michael Morris <tendo...@gmail.com> wrote:
> > 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.
>
> 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
>
>
