On Mon, Jun 8, 2026 at 5:00 PM Rowan Tommins [IMSoP] <[email protected]> wrote:
> On 08/06/2026 16:36, Alex Rock wrote: > > Recently, we had proposals for "Friend classes" and "Pure PHP files". > > These suggestions aren't new at all, but they demonstrate some wish in > > the PHP ecosystem to make certain changes for PHP to be closer to > > other programming languages. > > > I don't think "being closer to other programming languages" is, or > should be, an aim of the project. Our aim should be to make PHP as good > a language as it can be. > > That includes borrowing ideas which have proved successful in other > languages, large and small, as well as avoiding pitfalls which have been > revealed by those other languages. It also includes retaining PHP's > identity as a distinct language with its own history, user base, and > ecosystem. > > As I've said in previous discussions, JavaScript's module system was > designed around a very specific set of facilities and constraints. It > has some similarity to Python, which uses some of the same concepts > (e.g. all definitions are essentially anonymous objects, named by > assigning to variables). > > PHP has an entirely different set of facilities and constraints, much > more similar to Java and C# (e.g. all definitions have a globally unique > name, namespace imports are primarily short-hand for those unique names). > > Your proposal looks very much like trying to wedge JavaScript's solution > into PHP, rather than a realistic path forward for PHP's existing > ecosystem. > > > -- > Rowan Tommins > [IMSoP] > I see the bear is out for it's yearly walk eh? At least I wasn't the one who woke it this time. Kidding aside. Changing the language for change sake is a non-starter Alex. First, what is the problem you want to solve? The largest problem a module system could solve is resolving namespace conflicts. If you delve into the discussion Rowain and I had on this last year it goes into detail on this to some degree, but the real world problem is this. Suppose I write AkiPublish, a plugin for Wordpress which uses composer to resolve dependencies. Suppose someone else out there writes BobMod, a plugin to help moderate. For whatever reason the two plugins want to use different incompatible versions of a library called LogIt. The end user will have a crash if they ever install these plugins together. And if they're like 90% of WordPress users they won't have a clue why. PHP has no mechanism for code isolation - plugins, extensions, modules or whatever the heck you call them, they all must share a global state. Careful coding mitigates most of this problem and it is the reason Laravel, Symfony, Drupal et al take the form they do - avoiding establishing global variables at all cost and putting this into classes. But that isn't the architecture of WordPress and indeed most of PHP before 5.3. And while many are dismissive of Wordpress, it does have one of the largest, perhaps the largest, footprints in the PHP CMS space. True code isolation would be useful to have, but it needs to take a form that is minimally disruptive. Rowain and I had worked out some concepts, but I dropped the ball on this and got distracted with other projects. To be honest, these days I spend as little time working with computer code outside of work as I can because it just doesn't interest me anymore. I wrestle with Dorico and try to actually "compose". That said, at this time completion of the PHP-ASYNC project might be prerequisite to doing this. The reason is simple - the best way to isolate code packages is to put them on different threads. The moment that happens calls to functions living on those threads will have to be handled asynchronously. That's one of the reasons I've remained silent on this for much of the last year.
