On Sun, May 4, 2025, at 5:40 PM, Michael Morris wrote:
> On Sun, May 4, 2025 at 5:38 PM Larry Garfield <[email protected]> wrote:
>>
>> > PHP Code -----------------------------------------------------------------------
>> >
>> > namespace MyModule;
>> >
>> > yield function sum(a, b) { return a + b; }
>> >
>> > --------------------------------------------------------------------------------
>>
>> Every module author changes their code. (Which is reasonable.)
>
> Actually no. PHP Modules are only needed if the package author wants
> the functionality modules provide - specifically having an independent
> symbol table and autoload queue. Existing packages don't have to change
> in any way. If a module includes one their symbols will be written
> into that module's symbol table. If two modules include the same
> package they each write it onto their own respective symbol tables.
I thought it self-evident that I was referring to "every package author that wants to expose
their package as a module", not literally every owner of a package on Packagist. (Though
presumably over time those two circles will increasingly overlap.) But let me make that explicit.
And, as noted, requiring the author of a package to introduce new syntax in order to turn the
package into a module is a reasonable expectation. I have no issue with that.
>> > PHP Code -----------------------------------------------------------------------
>> >
>> > use require 'mymodule.php';
>> >
>> > echo MyModule::sum(3, 4);
>> > --------------------------------------------------------------------------------
>>
>> Every caller changes their code, to use use require and to use the
>> pseudo-class syntax to call the function.
>
> Again, if they want module functionality. No one *has* to do this - the
> new syntax was carefully chosen to let the existing syntax work as it
> always has.
If my library is structured as a module, with yield and stuff, then how exactly would someone use it
without using the use require syntax at least?
>> > PHP Code -----------------------------------------------------------------------
>> >
>> > use sum require 'mymodule.php';
>> >
>> > echo sum(3, 4); // 7
>> > --------------------------------------------------------------------------------
>>
>> Removes the pseudo-class syntax, but still has the "use sum require...." change
>> for the consumer.
>>
>> As described, the implication is that the millions of existing
>>
>> use Some\Class\Here;
>>
>> lines in code in the wild will... not work if the Some\Class package becomes a module?
>
> This is left up to the autoloader. When you call that use statement
> from the main thread the autoloader receives args ("Some\Class\Here",
> false). When you call that use statement from a module the autoloader
> receives arguments ("Some\Class\Here", "RequestingModule"). If the
> autoloader isn't rewritten it will ignore the 2nd argument and serve
> out the same code for both module and main thread.
I believe you are grossly misusing the term "thread" here. There is no separate execution
thread involved, just scoped symbol tables.
See note further down about the rest of the points raised here.
> HOWEVER, modules can define their own autoloaders and those will be
> executed independent of the autoloader on the main thread. Furthermore,
> the autoloader on the main thread will not be used unless the module
> opts into using it.
Nothing in your initial post discussed any of this, or even implied it.
>> I think that's what's implied, but it's not clear. If that triggers
>> autoloading, how does the autoloader know how to find it? It needs to know the module name, which
>> as described is the file name of the module, not the class.
>
> By convention the filename might be the module name, but that a
> convention of package management, autoloading, some future PSR-X that
> is far, far outside of scope here. The module's name is its namespace!
> For a module a namespace isn't just a run time string replacement, it
> has a very real effect. The namespace will be the 2nd argument of every
> autoload call made from the module or any file required/included in its
> scope. Existing packages don't need to be aware this is happening -
> but the module can have a custom autoloader that always loads version 2
> of a popular package even if composer on the main thread is set to
> include version 3.
From the proposal:
> use require 'mymodule.php';
>
> echo MyModule::sum(3, 4);
How exactly does MyModule get defined? That is not at all clear.
>> Since the module name is the file name, that means if a module has 50 internal classes, it
>> must be in the same file. Hence, giant files.
>
> I hope you can see why this isn't true now. The module entry file can
> simply yield out its public assets like so.
>
> namespace Vendor\Package;
> require 'autoloader.php';
> yield { A, B, C }
... Nothing in your initial proposal suggested that in the slightest. It did not even include yield
with brackets to list multiple options.
> The above assuming that the autoloader knows where \Vendor\Package\A,
> \Vendor\Package\B and \Vendor\Package\C are located at. If an
> autoloader isn't used they'll have to be explicitly required before
> being yielded out.
>
>>
>> If those reads of your post are inaccurate, then please show with examples how they are
>> inaccurate, because that is how I understood your proposal text at face value.
>>
>
> Ok, let's go over them in turn
>
>>> 1. Every module author to change their coding structure.
>
> No. Modules aren't replacing the current mechanism - just augmenting it
> when needed. The new syntax is only necessary when an independent
> symbol table is desired. Further, there's nothing stopping a package
> from having a standard require entry file that doesn't set up the
> symbol table and related protections, and one that does.
See above.
>>> 2. Every consumer of a package to change their coding structure
>
> That depends on the package maintainer. They can certainly rewrite the
> package such that consuming code must use module syntax to access it,
> but this isn't required of them. And as mentioned above they can get
> clever and provide multiple entry points to their code if they desire
> just as JavaScript package devs have been doing to make sure their
> packages work whether the consumer uses ESM import or CommonJS import.
>
>>> 3. Devs to abandon "it just works" autoloading and explicitly import
>>> packages.
>
> I don't know where you got that from - maybe the old thread from 9
> months ago? The proposal I made last night not only takes autoloading
> into account but also discusses how autoload functions will receive a
> second argument moving forward that lets them make decisions about what
> code to supply to modules based on whatever logic they have which is
> well beyond the scope of this proposal.
It came from the examples in the original proposal at the top of this thread:
> use sum require 'mymodule.php';
>
> echo sum(3, 4); // 7
So if I want to call sum(), I have to explicitly use sum require it. I cannot just let
the autoloader sort it out. (Assuming we were talking about a class or function autoloading ever
happens, of course.)
>>> 4. Abandoning 16 years of PSR-0/4 file convention in favor of "module =
>>> file", which will almost certainly result in multi-thousand-line files even for clean,
>>> well-factored code.
>
> Again, I don't see this, at all. And I'm a little insulted you'd think
> that I'm dumb enough to propose something that outrageous. Modules
> simply have their own symbol table scope. They can import any package
> as they exist today without any modification into that scope. They can
> therefore pull a different version of the same package, which is
> desirable if they have a compatibility issue with the latest version of
> the package. Those autoloader are important, but out of scope.
The implication from your original post is that if I want to import 3 symbols from a module, I
require a single file. That file has one or more symbols that are yield ed.
Implication: If I want 3 symbols in a module together, they have to be in the same file.
Your response here about having a fronting file that yields symbols it doesn't define, on the
assumption that an autoloader will figure it out in the backend, was never stated nor implied
anywhere in your proposal. Rather, it states that modules look like this:
> yield function sum(a, b) { return a + b; }
IE, like Javascript or Python libraries. That is the plain reading of your original post. And
naturally means that whoever is authoring that file needs to make changes to it, to at minimum add
the "yield" keyword.
So before you get indignant and call me a liar ("You're 4 for 4 on falsehoods"),
perhaps consider how someone you know is "more intelligent" than this can come away from
your post understanding it so utterly differently than what you intended.
From your follow up statements, it seems that what you are proposing is not "modules" in
any sense used in any language I am familiar with. Rather, you're proposing a symbol table
hack to get around PHP's inability to load two symbols with the same name, and using module
terminology to inaccurately describe it. (And thread terminology as well.) That is, it seems your
intent is that I can import arbitrary code from an arbitrary package and shunt it off to a separate
symbol table. But it's not clear if you intend for the package author to have to do anything
to enable that. Your answers seem contradictory.
For a concrete example, I'll offer my AttributeUtils library: https://github.com/Crell/AttributeUtils/tree/master/src
It has a whole bunch of interfaces, plus a few classes. We'll focus on a subset of them for
the moment.
Analyzer.php (this is the main class someone uses)
AttributeParser.php (this is an internal class used by Analyzer, you should never use it directly)
FromReflectionClass.php (an interface that other libraries implement to trigger certain
functionality in Analyzer)
Say I want to modularize this library, under your proposal. What would I, as the library author, do
exactly? Anything? How can I mark AttributeParser as internal-only and
thou-shalt-not-use-if-you're-not-me? (That's the most common value of module systems, and
the one most people in PHP seem to think of, from what I've seen.)
That library is used extensively by Serde (another of my libraries). If I modularize
AttributeUtils, then what changes does Serde need to make? What would it get out of doing so?
Code examples, please.
--Larry Garfield