On Wed, May 7, 2025 at 10:59 AM Larry Garfield <la...@garfieldtech.com> wrote:
> > 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 > No proposal that replaces or even significantly alters how require et al works will be taken seriously, much less gain traction. As long as a package has PHP files that require can parse then clever users can direct require the files of a package distributed this way. The only way to stop it is to truly make files meant to be used with this unreadable to require - and the simplest way to do that is to assume code first and drop support for <?php ?> in these files. I'm in favor of that since I believe the engine can parse the files faster because it should simplify the token parsing process quite a bit. But I don't think a majority, much less the required supermajority would be in favor of such a change, at least not without other compelling reasons. Rather than fight the co-existence with require I think it would be better to harness and work with it. This would also make the changeover easier. As for the point of whether this counts as a module - Ask 10 programmers what a module is and expect 12 different answers. I'm patterning this on the module pattern used in JavaScript. I'm sorry if that doesn't meet your definition of module. I am open to any other name - component? library? Calling it a module until a better name can be found will have to do. But I'm not going to insult my own proposal by calling it "name-mangling facade" Part of the problem is PHP deals with code on a per file basis, not on a per directory one. Speaking of facades, the PSR-4 loading recommendation of organizing classes puts a module/package facade onto PHP, but it in no way ever has worked that way. Modules and Packages traditionally do work on the directory level, but how do you affix such to a language that has never had it and prevent older mechanisms of the language, such as require, from doing an end run. This problem hasn't been solved for years for a reason - it's not simple. It is an easy one to give up on, as most have. I'm just too stupid to give up I suppose.
