Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:127301
Feedback-ID: i8414410d:Fastmail
Precedence: bulk
MIME-Version: 1.0
Date: Wed, 07 May 2025 09:57:22 -0500
To: "php internals" <internals@lists.php.net>
Message-ID: <4e0bc5b1-48af-4b4c-9d75-3d20245824f2@app.fastmail.com>
In-Reply-To: 
 <CAEUnE0eY7N_AtPeOm+HhU3yEEWfQDM87dVOkEu1o5cCaMg34hw@mail.gmail.com>
References: 
 <CAEUnE0c88jp9LeoHnngqvU+XjL_fpwPcfKi1g7hg6k6PBN6KCQ@mail.gmail.com>
 <9cbbe803-5fd1-4011-b42e-033d4ede3fe9@app.fastmail.com>
 <CAEUnE0fLxrMqZ44PG9-8cUbGbQ=19a+YT68TyxhrZRGwxw0hUA@mail.gmail.com>
 <15a33d20-47c1-443e-aafd-f39bd8f367c1@app.fastmail.com>
 <CAEUnE0dfmwSygnJu91jLcX5Hf5_NwY0SaW4tfprU0-5G_wNsSw@mail.gmail.com>
 <aca7c67d-2b8d-4e38-bd2c-3f9bcf88c09c@app.fastmail.com>
 <CAEUnE0eY7N_AtPeOm+HhU3yEEWfQDM87dVOkEu1o5cCaMg34hw@mail.gmail.com>
Subject: Re: [PHP-DEV] Modules, again.
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
From: larry@garfieldtech.com ("Larry Garfield")

On Tue, May 6, 2025, at 1:33 AM, Michael Morris wrote:
> Resetting and moving the proposal writeup to a github hosted markdown 
> file here: 
> https://github.com/michael-lloyd-morris/php-modules-rfc/blob/main/php-modules.md

>> 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)
>> 
>
>
> In answer to your question - assuming the module file is at the root of 
> your src directory.
>
> <?php 
> module \Crell\AnalyzerModule;
>
> export [
>   \Crell\Analyzer,
>   \Crell\FromReflectionClass
> ];
> ?>
> 
>> 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?  
>
> On that end
>
> <?php
> require_module <path_to_Crell\AnalyzerModule>;
>
> $analyzer = new \Crell\AnalyzerModule::Analyzer();
> ?>
>
> If the autoloader gets updated to identify and properly load modules 
> (outside the scope of this RFC) the require_module statement can be 
> dropped.  If a use statement is desired it looks like this
>
> <?php
> use \Crell\AnalyzerModule::Analyzer;  // This is legal for modules, not 
> for static classes.
>
> $analyzer = new Analyzer();
> ?>
>
> 
>> What would it get out of doing so?
>
> Nothing much - it just wouldn't be able to see as deeply into the 
> AttributeUtils code.

So it's not really giving private symbols.  It's not even blocking access to anything, since it can still just be included or autoloaded.  What you're proposing is really just an optional loading facade (the real kind of facade) that lets you pull random symbols into a separate symbol table, accessed via separate syntax.  (Either a class-like AnalyzerModule::Analyzer, or use-require.)

Putting aside for the moment the question of whether that is a good idea or not, it is definitely not "modules" in any typical sense.  I really don't think calling it "modules" is doing your proposal any favors, as it's just leading to confusion.  What you're describing is a name-mangling facade, or symbol table facade, or something like that.  (I don't know that there is a standard name.)

I strongly recommend you recast your terminology around that, rather than "modules."  That would remove a lot of confusion and allow people to review and respond to the idea you're actually proposing, now what they think a "module" should be.

--Larry Garfield