Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:123985 X-Original-To: internals@lists.php.net Delivered-To: internals@lists.php.net Received: from php-smtp4.php.net (php-smtp4.php.net [45.112.84.5]) by qa.php.net (Postfix) with ESMTPS id 38A0A1AD8EA for ; Fri, 28 Jun 2024 07:08:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=php.net; s=mail; t=1719558580; bh=VUu2tZk5up37L+QfxXqtlgAgeFVxrYAZ1RIPG2GqrwM=; h=References:In-Reply-To:From:Date:Subject:To:From; b=MEqTw2aJymo2OGM0+65pWbnVqngIzB4mXIS8mwUh5TRjWKW4NicgPgGC/yl35fpOu tEebQtt+gwyCxrh5Bnf2Io5EceffWDedqkidbn70pJlFzlQVbBiDuq6j/dLgD4k+JI RJyloT9nuHF5KZAjrHG2AiUIlo85AuMViaFQeoRzPoT6wAG71j0YGkozKCepkKBs7B lehb1mzGfWjQIgUEzhviBOZQ0K5LvCaHm1dplmR7aoKScYy0vSqubTyD+LroCZieBN ZuD0VUPr68asb6CD/5gCwVkpWY1QX6xNDuNfjOtgyCrzsXJOndpyWh+BuicmZL75eS 8MNMpMGWJQGXA== Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id 857111806DA for ; Fri, 28 Jun 2024 07:09:31 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_50,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,DMARC_PASS,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE, SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=4.0.0 X-Spam-Virus: Error (Cannot connect to unix socket '/var/run/clamav/clamd.ctl': connect: Connection refused) X-Envelope-From: Received: from mail-qv1-f53.google.com (mail-qv1-f53.google.com [209.85.219.53]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Fri, 28 Jun 2024 07:09:28 +0000 (UTC) Received: by mail-qv1-f53.google.com with SMTP id 6a1803df08f44-6b5136965a7so1723956d6.1 for ; Fri, 28 Jun 2024 00:08:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719558489; x=1720163289; darn=lists.php.net; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=Q7aAAGUw7VjqmfCeQIH54j+RfNpWopVmLiA3dYU9puo=; b=ahBNcwFKGFoapTDQlWJ0E+qIhQwoOWjqiRvlVY8eGRVvkdFItoLU3Bln9DV02Xf9Yf zkxfF/2GEuRiaJGo8XUCiXlt5i/KT1aiW88XLSdma4C4gyuhwdHIIZEtYszCzu5H/9zU +WdvrN6NtrdFeWy4omgCVKNaz5KP3cz00o3E56Y7BepXUhPOg5jfSBgJtB1OZqdogTyi Cq3u2Cxs9mgImLJCZiPNKahg8O2FNn4Vobyqo7FCP2W5x21Ls5CPNXoxgwAcKMcnNiIW LkTDsy0rjdZ280goZPZyK/v64r3sNVqKS9gWMn4DREpTtpvaNU2S7DIr24dLeUBT3LE8 I5Cg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719558489; x=1720163289; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=Q7aAAGUw7VjqmfCeQIH54j+RfNpWopVmLiA3dYU9puo=; b=ricJ+a98kwfsjReZPRYkKDyrjEaO1pv4j1x25v7ATKXF+EkQRmlkFGc8pXjKV6Z+Vp LyOb3Sy4+7W/BOWp9nPrzd2y7fEdPSUCz/DW1U9OyIfvsHNWIXNoMrc5b7JXFGyvsCg7 HV6LyOKlSCwbuiROzVj4vmknGkaNVS+MX6k0GttSg9pwr7c3FZRMCmjZLV6BytykU92N HYt3VSmoLq7igmCT/LtTomrl24uvtW6mBSXwmw1ksU4MfLRK20sHvKrnDLZ5zOFClfwB jxrc/xtOZFvFfleqi+Dl8XNSkAsN2CXHBIkBOuelviB8y8DtnmA57JJ2BMiJ2u/vblPp iYVw== X-Gm-Message-State: AOJu0Yyd3ZgsjecEy3ujZjJ+xXJbdwWLNV7KDJyEoSBdtmxzxTbJL0EU I4jK2Yw6tvCWK9jLuR2sPDN92qpsj+Jo77UlySWHQDPMlk0yb7B7TR3ynhhx+DBiItOH8p3/6rd BctWuA14RwmsJUWmNbkCK/yQYHlR09Qrp X-Google-Smtp-Source: AGHT+IEpH57vAvQ3MP96kmeSTHdCOnJzqWj/zg5Eipqvb2WfOBioguOT0hAcF5+6j/wiiH8+KPh6+FwvZj2UPQwqAOU= X-Received: by 2002:a05:6214:19ea:b0:6b4:febe:e86b with SMTP id 6a1803df08f44-6b54099c35amr231737626d6.4.1719558488170; Fri, 28 Jun 2024 00:08:08 -0700 (PDT) Precedence: bulk list-help: list-post: List-Id: internals.lists.php.net MIME-Version: 1.0 References: <0acedb8e-34be-4348-907b-4075cf7641fd@app.fastmail.com> <9c20b078-f82a-47fe-af23-2f3cdd233079@app.fastmail.com> In-Reply-To: <9c20b078-f82a-47fe-af23-2f3cdd233079@app.fastmail.com> Date: Fri, 28 Jun 2024 03:07:55 -0400 Message-ID: Subject: Re: [PHP-DEV] [Initial Feedback] PHP User Modules - An Adaptation of ES6 from JavaScript To: PHP internals Content-Type: multipart/alternative; boundary="000000000000dba69d061bede826" From: tendoaki@gmail.com (Michael Morris) --000000000000dba69d061bede826 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This is a very long reply to several emails. On Thu, Jun 27, 2024 at 5:45=E2=80=AFPM Jim Winstead wrote: > The angle I am coming at this from is improving the developer experience > around "packages" or "modules" or whatever you want to call them, and so > much of this proposal doesn't seem to be about that. > > Ok, first problem - not a proposal really, but a ramble trying to get to a proposal. Before I made the first post the idea was knocking around in my head and wouldn't go away, so I just stream of consciousness listed what's going through my head. That leads to the second point you made. > I could have made that point in other ways, and I'm sorry that my first > attempt came off as insulting. It really concerned me when I already saw > discussion about taking this off-list and going into the weeds on technic= al > details when the problem that is being addressed by this proposal is > extremely unclear to me. > It is unclear even to me. Perhaps I shouldn't have posted out something this half baked. That said, pruning off large sections of language functionality is a distraction. For now let's just note that it is a possibility to improve the language this way afforded by the fact that import would be new way of bringing scripts in. Could isn't should. Also, at the moment again it's a distraction. Let's focus down on how code is imported. First though, a history review, partially to get this straight in my own head but hopefully of use for those following along. Why? Knowing how we got we are is important to some degree to chart a way forward. PHP started as a template engine. By modern standards, and compared to the likes of twig, it's a very bad template engine, but that doesn't really matter because it's evolved into a programming language in it's own right over the last nearly 20 years. Include, include_once, require, and require_once have been around since the beginning as the way to splice code files together. The behavior of these statements calls back to PHP's origin as a template engine as they do things similar mechanisms like JavaScript's import do not do (and for that matter, their equivalents in C# and Java). Their scope behavior is very different from import mechanisms in other languages, as they see the variables in the scope of the function they were invoked from or the global scope when called from there. Their parsing can be aborted early with a return. They can return a value, which is quite unusual to be honest. None of this is bad per se, but it is different and the question arises is it necessary. One artifact of their behavior that is bad in my opinion is that they start from the standpoint of being text or html files. If the included file has no PHP tags then the contents get echoed out. If there are no output buffers running this can cause headers to be set and fun errors to be had. So they can't be used to create files that can only echo explicitly (that is, a call to the echo statement or the like). Fast forward a bit - PHP 5.3, and the introduction of namespaces were introduced to deal with the overloaded symbol tables. They are a bit a hotwire as (if I'm not mistaken, it's been a couple years since I read the discussion on it) they just quietly prepend the namespace string in front of the name of all new symbols declared in the namespace for use elsewhere. As a result, PHP namespaces don't do some of the things we see in the namespaces of other languages (looking at Java and C# here). For example, privacy modifiers within a namespace aren't a thing. Very quickly after PHP 5.3 released autoloaders showed up. At some point support for multiple autoloaders was added. Several schema were added, PSR-4 won out, and composer showed up to leverage this. Composer is based on NPM, even to the point where json is used to configure it, and the composer.json file is fairly close to npm's package.json file even now. It's a userland solution, but to my knowledge WordPress is the only widely used PHP application out there that doesn't use it directly (there is a Composer Wordpress project). Before composer, and before namespaces there was PECL. Composer has eclipsed it because PECL has the limitation of being server-wide. It never really caught on in the age of virtual hosting with multiple PHP sites running on one box. Today we have Docker, but that didn't help PECL make a comeback because by the time docker deployment of PHP sites became the norm composer had won out. Also, composer library publishing is more permissive than PECL. I'll stop here lest this digress into a Composer v PECL discussion - suffice to say stabs a bringing code packages into PHP isn't a new idea, and a survey of what's been done before, what was right about those attempts and what was wrong needs to be considered before adding yet another php package system into the mix. The main influence of composer and autoloaders for preparing packages is that PHP has become far more Object Oriented than it was before. Prior to PHP 5.3 object oriented programming was a great option, but since autoloaders cannot bring in functions (at least not directly, they can be cheated in by bundling them in static classes which are all but namespaces) the whole ecosystem has become heavily object oriented. That isn't a bad thing. But it does need to be acknowledged. Before I go further I'll now respond to some other points made by others in this thread. On Thu, Jun 27, 2024 at 6:01=E2=80=AFPM Jordan LeDoux wrote: > > Ah, yes, THAT'S a fair point. While the idea of optimizing the > engine/parser for modules has merit as part of a user modules proposal, I > agree that many of the specifics proposed here feel pretty scatter-shot a= nd > unclear. > > The scoping operator change I simply ignored, as that feels to me like > just asking "I would like to program in Node" and there's no clear benefi= t > to changing the scoping operator outlined, while there is a clear detrime= nt > to eliminating the concatenation operator entirely. > > Mostly I ignored that aspect of it, because I assumed that all the people > capable of implementing this proposal would just refuse stuff like that > outright, and that the inclusion of it would guarantee the RFC fails, so = no > point in worrying. > > But the broader question you are presenting about the focus and goals of > the proposal, and how the specifics relate to that, is actually a questio= n > that I share. > I hope the above begins to address that. Package management I think should be the main topic, and from here forward I'll leave aside any unnecessary parser changes that might occur when code is imported as there are distractions. Those I continue to bring up I'll state why, and those who are more familiar with how the engine works can speak to whether such changes truly are useful or unecessary. If I'm wrong, then dropping such suggestions entirely is the way to go. On Thu, Jun 27, 2024 at 6:07=E2=80=AFPM Rob Landers wro= te: > > Internals has made it pretty clear: no more declare or ini entries (unles= s > it is absolutely needed). > Noted. > > I personally don=E2=80=99t like it because it uses arrays, which are opaq= ue, easy > to typo, and hard to document/check. > > Instead, maybe consider a new Reflection API? > > (new ReflectionModule)->import('MyModule')->run() > That doesn't solve the problem of how the parser figures out where the code is. That's got to happen somewhere. I'll come back to this in a moment. > Keep in mind that extensions typically expose functions automatically, an= d > under the original proposal those functions have to be imported to be use= d: > `import mysql_query` > > > they also do now, unless you either prefix them with \ or rely on the > fallback resolution system. I=E2=80=99m honestly not sure we need a new s= yntax for > this, but maybe just disable the global fallback system in modules? > > I'm not sure that's a good idea, neither was this. > > Perhaps PHP imports, unlike their JavaScript or even Java C# counterparts= , > could be placed in try/catch blocks, with the catch resolving what to do = if > the import misses. > > Which is something I wrote, yet a day later - yuck. I do not like. But I'= m in brainstorm mode, playing with ideas with everyone. > I really don't like the extension games seen in node with js, cjs and mjs= , > but there's a precedent for doing it that way. In their setup if you've > set modules as the default parse method then cjs can be used to identify > files that still need to use CommonJS. And mjs can force the ES6 even in > default mode. But it is a bit of a pain and feels like it should be > avoided. > > > I would argue that it be something seriously considered. Scanning a > directory in the terminal, in production systems, while diagnosing ongoin= g > production issues, it can be very handy to distinguish between the =E2=80= =9Cold > way=E2=80=9D and =E2=80=9Cnew way=E2=80=9D, at a glance. > > Fair point. > > > > > the only thing I don=E2=80=99t like about this import/export thing is tha= t it > reminds me of the days when we had to carefully order our require_once > directives to make sure files were loaded before they were used. So, I > think it is worth thinking about how loading will work and whether loadin= g > can be dynamic, hoisted out of function calls (like js), how order matter= s, > whether packages can enrich other packages (like doctrine packages) and i= f > so, how much they can gain access to internal state, etc. This is very mu= ch > not =E2=80=9Ca solved problem.=E2=80=9D > > > In JavaScript import must be top of the file - you'll get an error if you > try an import following any other statement unless it's a dynamic import(= ), > which is a whole other Promise/Async/Kettle of fish that thankfully PHP > does not have to take into account as, until you get used to it (and even > after), async code is a headache. > > > Are you sure? I don=E2=80=99t remember them removing import hoisting, but= it=E2=80=99s > probably more of a typical linting rule because it is hard to reason abou= t. > Likely correct - I do use linters heavily. Hoisting is evil (necessary, but still evil). On Thu, Jun 27, 2024 at 6:13=E2=80=AFPM Rowan Tommins [IMSoP] wrote: > > Thank you for sharing. I think it's valuable to explore radical ideas > sometimes. > > I do think PHP badly needs a native concept of "module" or "package" - > in fact, I'm increasingly convinced it's the inevitable path we'll end > up on at some point. BUT I think any such concept needs to be built on > top of what we have right now. That means: > > - It should build on or work in harmony with namespaces, not ignore or > replace them > - It should be compatible with Composer, but not dependent on it > - It should be easy to take existing code, and convert it to a > module/package > - It should be easy to carry on using that module/package after it's > been converted > On all these points, agreed. > > If we can learn from other languages while we do that, I'm all for it; > but we have to remember that those languages had a completely different > set of constraints to work with. > > For instance, JS has no concept of "namespaces", but does treat function > names as dynamically scoped alongside variables. So the module system > needed to give a way of managing how you imported names from one scope > to another. That's not something PHP needs, because it treats all names > as global, and namespaces have proved an extremely successful way of > sharing code without those names colliding. > > Very good point. > > Other parts of your e-mail are essentially an unrelated idea, to have > some new "PHP++" dialect, where a bunch of "bad" things are removed. > Let's set that aside then. Better package management is a big enough dragon to slay. On Thu, Jun 27, 2024 at 8:16=E2=80=AFPM Mike Schinkel = wrote: > This is a long reply rather than send a bunch of shorter emails. > > > On Jun 27, 2024, at 2:10 PM, Deleu wrote: > > > > Overall, I think PHP has already reached the limit of surviving with > only PSR-4 and Composer. Single class files were a great solution to get = us > out of the nightmare of `require` and `import` on top of PHP files. But > more than once I have had the desire to declare a couple of interfaces in= a > single file, or a handful of Enums, etc. > > This. > > I cannot overemphasize how nice it is to work in Go where I can put almos= t > any code I want in any file I want without having to think about > autoloading. > Go is cool. I need to use it more. These days JavaScript gets most of my time, but PHP will always be the language that got me into programming professionally and for that I'll be eternally grateful. > > As I understand the proposal, this would have no BC issues for code not i= n > modules. PHP could then set rules for code in modules that would not to b= e > directly compatible with code outside modules. > That is the goal. Module code should be allowed to be different if the optimization makes for faster running and easier to understand code (for the programmer, the IDE, and the parser itself). Changing things for the sake of changing them, no. > > At least to me this does not feel as big as trying to implement unicode. > I would hope not, because that turned out to be well night impossible. > > > 2. No need for autoloaders with modules; I assume this would be > obvious, right? > > > > Depends largely on whether modules can include and require to get acces= s > to old code. I also didn't discuss how they behave - do they share their > variables with includes and requires? > > I was presuming that all old code would use autoloaders but modules would > be free to do it a better way. > If you need to call code from a namespace from inside a module, sure, the > autoloader would be needed. > This is correct and what I had in mind. > > > 6. Modules should be directories, not .php files. Having each file be a > module makes code org really hard. > > > > Yes, but that is how JavaScript currently handles things. It is > currently necessary when making large packages to have an index.js that > exports out the public members of the module. This entry point is > configurable through the package.json of the module. > > I am envisioning that there could be a module metadata file that would > have everything that PHP needs to handle the module. It could even be > binary, using protobufs: > An interesting idea. I need to research this some. > node_modules IMO is one of the worse things about the JavaScript > ecosystem. Who has not seen the meme about node_modules being worse than = a > black hole? > Fair enough. Or maybe import maps would be a better way forward. > > But ensuring that it is possible to disallow loading needs to be > contemplated in the design. PHP has to be able to know what is a module a= nd > what isn't without expensive processes. > One possible solution is that if modules do not have tags, ever, and someone directly tries to load a module through http(s) the file won't execute. Only files with tags are executable by the web sapi. > > > 10. Having exports separate from functions and classes seems like it > would be problematic. > > > > Again, this is how they work in JavaScript. Not saying that's the best > approach, but even if problematic it's a solved problem. > > I have evidently not written enough JavaScript to realize that. > JavaScript is an odd prototypical duck. Everything ultimately is an object. Tha > > > I'm also interested in learning on how other module systems out there d= o > work. > > I am very familiar with modules (packages) in GoLang and think PHP could > benefit from considering how they work, too. > > I've only touched the surface on how GoLang does things. Some of it was confusing to me at first. It's also been awhile so I'd need to refresh my memory to speak to it. > > On Jun 27, 2024, at 3:22 PM, Michael Morris wrote: > > Composer would need a massive rewrite to be a part of this since it > currently requires the file once it determines it should do so. If we do = a > system where import causes the parser to act differently then that alone > means imports can't be dealt with in the same manner as other autoloads. > > That is why I am strongly recommending a modern symbol resolution system > within modules vs. autoloading. > > Ok. > >> I'm not fond of this either. > > > > There will need to be a way to define the entrypoint php. I think > index.php is reasonable, and if another entry point is desired it can be > called out -> "mypackage/myentry.php" > > Why is an entry point needed? If there is a module metadata file as I am > proposing PHP can get all the information it needs from that file. Maybe > that is the `.phm` file? > > Maybe. Again, I need to look over this meta data format. Also, how does it get created? > > On Jun 27, 2024, at 4:54 PM, Rob Landers wrote: > >> Thanks. The sticking point is what degree of change should be > occurring. PHP isn't as behind an 8-ball as JavaScript is since the dev c= an > choose their PHP version and hence deprecation works most of the time for > getting rid of old stuff. But not always. Changes that are incompatible > with what came before need a way to do things the old way during > transition. Again, see PHP 6 and unicode, which snowballed until it was > clear that even if PHP 6 had been completed it wouldn't be able to run mo= st > PHP 5 code. > > > > It=E2=80=99s not just up to the dev, but the libraries we use and wheth= er or not > we can easily upgrade (or remove) them to upgrade the php version. > > By "upgrade" then, do you mean convert them into modules, or just be able > to use them as-is. > > As I read it and am envisioning it, there would be no changes needed to b= e > able to use them as-is. > > Any system that blocks existing code from being used would be a non-starter for inclusion. > > I think it would be a mistake to exclude old code and/or prevent > templating. Not only are there now decades old code in some orgs, but how > would you write an email sender that sent templated emails, provide html, > generate code, etc? There has to be an output from the code to be useful. > > Excluding old code or templates from modules would not exclude them from > working as they currently do outside modules. As I see it, modules would > be more about exporting classes and functions, not generating output per = se. > > So all that decades of old code could continue to exist outside modules, > as it currently does today. > > Exactly this. > > I think it=E2=80=99s fine to use js as an inspiration, but it isn=E2=80= =99t the only one > out there. There is some precedent to consider directories as modules (go > calls them =E2=80=9Cpackages=E2=80=9D) and especially in PHP where namesp= aces (due to PSR-4 > autoloading) typically match directory structures. > > Totally agree about inspiration for modules outside JS, but not sure that > PHP namespaces are the best place to look for inspiration. > > Namespaces by their very nature were designed to enable autoloading with = a > one-to-one file to class or interface, and by nature add conceptual scope > and complexity to a project that would not be required if a modern > module/package system were added to PHP. > > Modules could and IMO should be a rethink that learns the lessons other > languages have learned over the past decade+. > > Agreed. > >> Node.js uses package.json and the attendant npm to do this sort of pre= p > work. And it's a critical part of this since modules can be versioned, a= nd > different modules may need to run different specific versions of other > modules. > > > > Please, please, please do not make a json file a configuration language= . > You can=E2=80=99t comment in them, you can=E2=80=99t handle =E2=80=9Cif p= hp version <9, load this, > or if this extension is installed, use this.=E2=80=9D > > > > Maybe that is desirable, but doing things slightly different based on > extensions loaded is def a thing. > > I don't think commenting is important in this file, or even desired. > > As I proposed above, these could be protobuf or phar. These should be > build artifacts that can be generated on the fly during development or fo= r > newbies even during deployment, not hand-managed. > Hand management has value in learning the underlying concepts though. > > I could see the generation of two files; one in binary form and one that > is readonly so a developer can double-check what is in the current protob= uf > or phar file. > > >> Those are implementation details a little further down the road than > we're ready for, I think. > > > > Personally, if these are going to have any special syntax, we probably > shouldn=E2=80=99t call them .php files. Maybe .phm? > > I was going to suggest that, and then remembered earlier PHP when there > were multiple file extensions and that was a nightmare. > > This does remind me to mention that I think there should be a required > "module" declaration at the top of each file just like Go requires a > "package" declaration at the top of each file. That would make it trivial > for tooling to differentiate, even with grep Fun idea, if the @ operator is ditched as an error suppression operator it could be used as the package operator. (If I manage to talk everyone into getting rid of one thing, it's @). > . > > > the only thing I don=E2=80=99t like about this import/export thing is t= hat it > reminds me of the days when we had to carefully order our require_once > directives to make sure files were loaded before they were used. So, I > think it is worth thinking about how loading will work and whether loadin= g > can be dynamic, hoisted out of function calls (like js), how order matter= s, > whether packages can enrich other packages (like doctrine packages) and i= f > so, how much they can gain access to internal state, etc. This is very mu= ch > not =E2=80=9Ca solved problem.=E2=80=9D > > That is why I proposed having a "compiled" module symbol table to > eliminate most (all?) of those issues. > The more you bring it up, the more I am reminded of the import-map directive added to client-side JavaScript. > > > On Jun 27, 2024, at 6:00 PM, Rowan Tommins [IMSoP] > wrote: > > I do think PHP badly needs a native concept of "module" or "package" - > in fact, I'm increasingly convinced it's the inevitable path we'll end up > on at some point. BUT I think any such concept needs to be built on top o= f > what we have right now. That means: > > > > - It should build on or work in harmony with namespaces, not ignore or > replace them > > It may be an unpopular opinion, but I would argue that namespaces were > optimized for autoloading and the one class/interface per file paradigm, > not to mention to regrettable choice of using the escape operator to > seperate namespaces and that fact that PHP throws away a lot of informati= on > about namespaces at runtime. > I remember when the choice to use \ was made. I've rarely been so angry about a language design choice before or since. I've gotten used to it, but seeing \\ all over the place in strings is still.. yuck. > > IMO allowing modules to eventually deprecate namespaces =E2=80=94 at leas= t in a > defacto form of deprecation =E2=80=94 would allow modules to be much bett= er than if > the try to cling to a less desirable past. > > > - It should be easy to take existing code, and convert it to a > module/package > > Maybe, but not if that means modules retain baggage that should really be > jettisoned. > > > and namespaces have proved an extremely successful way of sharing code > without those names colliding. > > At the expense of a lot more complexity than necessary, yes. > > Managing symbols in a module need not be a hard problem if PHP recognizes > modules internally rather than trying to munge everything into a global > namespace like with namespaces. > I'm inclined to agree on these points, but I also don't know the engine internals that wall. Intuitively it would seem keeping the symbol table small would make the code go faster. > > On Jun 27, 2024, at 6:41 PM, Larry Garfield > wrote: > > What problem would packages/modules/whatever be solving that isn't > already adequately solved? > > Not speaking for Michael, obviously, but speaking for what I envision: > > 1. Adding a module/package system to PHP with modern module features > - including module private, module function, and module propertie= s > 2. Providing an alternative to auto-loader-optimized namespaces. > - better code management and better page load performance > > Couldn't have said it better myself. > > Do we want: > > > > 1. Packages and namespaces are synonymous? (This is roughly how JVM > languages work, I believe.) > > 2. Packages and files are synonymous? (This is how Python and > Javascript work.) > > 3. All packages correspond to a namespace, but not all namespaces are a > package? > > I would argue packages (modules) should be orthogonal to namespaces to > allow modules to be optimized for what other languages have learned about > packages/modules over the past decade+. > > The fact that namespaces use the escape character as a separator, that PH= P > does not keep track of namespace after parsing is enough reason to move o= n > from them, and that they were optimize for one-to-one symbol to file > autoload are enough reasons IMO to envision a way to move on from them. > > > And given the near-universality of PSR-4 file structure, what impact > would each of those have in practice? > > Orthogonal. Old way vs new way. But still completely usable, just not a= s > modules without conversion. > > The fact PSR-4 exists is an artifact of autoloading single-symbol files > and thus a sunken cost does not mean that PHP should not cling to for > modules just because they currently exist. > > I have nothing to add to the above. --000000000000dba69d061bede826 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
This is a very long reply to several emai= ls.

On Thu, Jun 27, 2024 at 5:45=E2=80=AFPM Jim Winstead <jimw@trainedmonkey.com> wrote:
The angle I a= m coming at this from is improving the developer experience around "pa= ckages" or "modules" or whatever you want to call them, and = so much of this proposal doesn't seem to be about that.


Ok, first problem - not a proposal really, but a ramble trying to ge= t to a proposal. Before I made the first post the idea was knocking around = in my head and wouldn't go away, so I just stream of consciousness list= ed what's going through my head. That leads to the second point you mad= e.
=C2=A0
=
I could have made that point in ot= her ways, and I'm sorry that my first attempt came off as insulting. It= really concerned me when I already saw discussion about taking this off-li= st and going into the weeds on technical details when the problem that is b= eing addressed by this proposal is extremely unclear to me.
=

=C2=A0It is unclear even to me. Perh= aps I shouldn't have posted out something this half baked. That said, p= runing off large sections of language functionality is a distraction. For n= ow let's just note that it is a possibility to improve the language thi= s way afforded by the fact that import would be new way of bringing scripts= in.=C2=A0 Could isn't should.=C2=A0 Also, at the moment again it's= a distraction. Let's focus down on how code is imported.
First though, a history review, partially to get this straight = in my own head but hopefully of use for those following along. Why? Knowing= how we got we are is important to some degree to chart a way forward.

PHP started as a template engine. By modern=C2=A0stand= ards, and compared to the likes of twig, it's a very bad template engin= e, but that doesn't really matter because it's evolved into a progr= amming language in it's own right over the last nearly 20 years.
<= div>
Include, include_once, require, and require_once have be= en around since the beginning as the way to splice code files together. The= behavior=C2=A0of these statements calls back to PHP's=C2=A0origin as a= template engine as they do things similar mechanisms like JavaScript's= import do not do (and for that matter, their equivalents in C# and Java). = Their scope behavior is very different from import mechanisms in other lang= uages, as they see the variables in the scope of the function they were inv= oked from or the global scope when called from there.=C2=A0 Their parsing c= an be aborted early with a return.=C2=A0 They can return a value, which is = quite unusual to be honest. None of this is bad per se, but it is different= and the question arises is it necessary.

One arti= fact of their behavior that is bad in my opinion is that they start from th= e standpoint of being text or html files.=C2=A0 If the included file has no= PHP tags then the contents get echoed out. If there are no output buffers = running this can cause headers to be set and fun errors to be had. So they = can't be used to create files that can only echo explicitly (that is, a= call to the echo statement or the like).

Fast for= ward a bit - PHP 5.3, and the introduction of namespaces were introduced to= deal with the overloaded symbol tables. They are a bit a hotwire as (if I&= #39;m not mistaken, it's been a couple years since I read the discussio= n on it) they just quietly prepend the namespace string in front of the nam= e of all new symbols declared in the namespace for use elsewhere. As a resu= lt, PHP namespaces don't do some of the things we see in the namespaces= of other languages (looking at Java and C# here). For example, privacy mod= ifiers within a namespace aren't a thing.

Very= quickly after PHP 5.3 released autoloaders showed up. At some point suppor= t for multiple autoloaders was added.=C2=A0 Several schema were added, PSR-= 4 won out, and composer showed up to leverage this. Composer is based on NP= M, even to the point where json is used to configure it, and the composer.j= son file is fairly close to npm's package.json file even now.=C2=A0 It&= #39;s a userland solution, but to my knowledge WordPress is the only widely= used PHP application out there that doesn't use it directly (there is = a Composer Wordpress project).

Before composer, an= d before namespaces there was PECL.=C2=A0 Composer has eclipsed it because = PECL has the limitation of being server-wide. It never really caught on in = the age of virtual hosting with multiple PHP sites running on one box. Toda= y we have Docker, but that didn't help PECL make a comeback because by = the time docker deployment of PHP sites became the norm composer had won ou= t.=C2=A0 Also, composer library publishing is more permissive than PECL. I&= #39;ll stop here lest this digress into a Composer v PECL discussion - suff= ice to say stabs a bringing code packages into PHP isn't a new idea, an= d a survey of what's been done before, what was right about those attem= pts and what was wrong needs to be considered before adding yet another php= package system into the mix.

The main influence o= f composer and autoloaders for preparing packages is that PHP has become fa= r more Object Oriented than it was before.=C2=A0 Prior to PHP 5.3 object or= iented programming was a great option, but since autoloaders cannot bring i= n functions (at least not directly, they can be cheated in by bundling them= in static classes which are all but namespaces) the whole ecosystem has be= come heavily object oriented.

That isn't a bad= thing.=C2=A0 But it does need to be acknowledged.=C2=A0 Before I go furthe= r I'll now respond to some other points made by others in this thread.= =C2=A0


On Thu, Jun 27, 2024 at 6:01=E2=80=AFPM Jordan Le= Doux <jordan.ledoux@gmail.com= > wrote:
=

Ah, yes, THAT'S a fair point. While the idea of optimizing the engine/= parser for modules has merit as part of a user modules proposal, I agree th= at many of the specifics proposed here feel pretty scatter-shot and unclear= .

The scoping operator change I simply ignored, as= that feels to me like just asking "I would like to program in Node&qu= ot; and there's no clear benefit to changing the scoping operator outli= ned, while there is a clear detriment to eliminating the concatenation oper= ator entirely.

Mostly I ignored that aspect of it,= because I assumed that all the people capable of implementing this proposa= l would just refuse stuff like that outright, and that the inclusion of it = would guarantee the RFC fails, so no point in worrying.

But the broader question you are presenting about the focus and goals= of the proposal, and how the specifics relate to that, is actually a quest= ion that I share.

I hope = the above begins to address that.=C2=A0 Package management I think should b= e the main topic, and from here forward I'll leave aside any unnecessar= y parser changes that might occur when code is imported as there are distra= ctions. Those I continue to bring up I'll state why, and those who are = more familiar with how the engine works can speak to whether such changes t= ruly are useful or unecessary. If I'm wrong, then dropping such suggest= ions entirely is the way to go.=C2=A0



On Thu, Jun 27, 2024 at 6:07=E2=80=AFPM Rob L= anders <rob@bottled.codes> wrote:

Internals has made it pretty clear: no more declare or in= i entries (unless it is absolutely needed).

Noted.
=C2=A0
<= /div>

I personally don=E2=80=99t like it because it uses= arrays, which are opaque, easy to typo, and hard to document/check.

Instead, maybe consider a new Reflection API?

(new ReflectionModule)->import('MyModule'= )->run()

That does= n't solve the problem of how the parser figures out where the code is.= =C2=A0 That's got to happen somewhere.=C2=A0 I'll come back to this= in a moment.


Keep in = mind that extensions typically expose functions automatically, and under th= e original proposal those functions have to be imported to be used: `import= mysql_query`

they al= so do now, unless you either prefix them with \ or rely on the fallback res= olution system. I=E2=80=99m honestly not sure we need a new syntax for this= , but maybe just disable the global fallback system in modules?


I'm not sure = that's a good idea, neither was this.
=C2=A0

Perhaps PHP imports, unlike their J= avaScript or even Java C# counterparts, could be placed in try/catch blocks= , with the catch resolving what to do if the import misses.
Which is something I wrote, ye= t a day later - yuck. I do not like. But I'm in brainstorm mode, playin= g with ideas with everyone.=C2=A0


I really don't like the extension games s= een in node with js, cjs and mjs, but there's a precedent for doing it = that way.=C2=A0 In their setup if you've set modules as the default par= se method then cjs can be used to identify files that still need to use Com= monJS.=C2=A0 And mjs can force the ES6 even in default mode.=C2=A0 But it i= s a bit of a pain and feels like it should be avoided.

I would argue that it be something seriou= sly considered. Scanning a directory in the terminal, in production systems= , while diagnosing ongoing production issues, it can be very handy to disti= nguish between the =E2=80=9Cold way=E2=80=9D and =E2=80=9Cnew way=E2=80=9D,= at a glance.=C2=A0


<= /div>
Fair point.=C2=A0
=C2=A0=


the only thing I don=E2=80=99t like about this import/export thing is th= at it reminds me of the days when we had to carefully order our require_onc= e directives to make sure files were loaded before they were used. So, I th= ink it is worth thinking about how loading will work and whether loading ca= n be dynamic, hoisted out of function calls (like js), how order matters, w= hether packages can enrich other packages (like doctrine packages) and if s= o, how much they can gain access to internal state, etc. This is very much = not =E2=80=9Ca solved problem.=E2=80=9D
In JavaScript import must be top of the file - you'll get = an error if you try an import following any other statement unless it's= a dynamic import(), which is a whole other Promise/Async/Kettle of fish th= at thankfully PHP does not have to take into account as, until you get used= to it (and even after), async code is a headache.

Are you sure? I don=E2=80=99t remember them r= emoving import hoisting, but it=E2=80=99s probably more of a typical lintin= g rule because it is hard to reason about.=C2=A0

Likely correct - I do use linters heavily.=C2= =A0 Hoisting is evil (necessary, but still evil).
=C2=A0

On Thu, Jun 27, 2024 at 6:13=E2=80=AFPM Rowan Tommins [IMSoP] &l= t;imsop.php@rwec.co.uk> wrot= e:

Thank you= for sharing. I think it's valuable to explore radical ideas
sometim= es.

I do think PHP badly needs a native concept of "module"= ; or "package" -
in fact, I'm increasingly convinced it= 9;s the inevitable path we'll end
up on at some point. BUT I think a= ny such concept needs to be built on
top of what we have right now. That= means:

- It should build on or work in harmony with namespaces, not= ignore or
replace them
- It should be compatible with Composer, but = not dependent on it
- It should be easy to take existing code, and conve= rt it to a
module/package
- It should be easy to carry on using that = module/package after it's
been converted

On all these points, agreed.
=C2=A0

If we can learn from other languages= while we do that, I'm all for it;
but we have to remember that thos= e languages had a completely different
set of constraints to work with.<= br>
For instance, JS has no concept of "namespaces", but does = treat function
names as dynamically scoped alongside variables. So the m= odule system
needed to give a way of managing how you imported names fro= m one scope
to another. That's not something PHP needs, because it t= reats all names
as global, and namespaces have proved an extremely succe= ssful way of
sharing code without those names colliding.


Very good point.
=C2=A0

Other parts of your e-mail are e= ssentially an unrelated idea, to have
some new "PHP++" dialect= , where a bunch of "bad" things are removed.

Let's set that aside then.=C2=A0 Better package managem= ent=C2=A0is a big enough dragon to slay.



On Thu, Jun 27, 2024 at 8:16=E2=80=AFPM Mike= Schinkel <mike@newclarity.net> wrote:
Thi= s is a long reply rather than send a bunch of shorter emails.

> O= n Jun 27, 2024, at 2:10 PM, Deleu <deleugyn@gmail.com> wrote:
>
> Overal= l, I think PHP has already reached the limit of surviving with only PSR-4 a= nd Composer. Single class files were a great solution to get us out of the = nightmare of `require` and `import` on top of PHP files. But more than once= I have had the desire to declare a couple of interfaces in a single file, = or a handful of Enums, etc.

This.

I cannot overemphasize how = nice it is to work in Go where I can put almost any code I want in any file= I want without having to think about autoloading.
Go is cool. I need to use it more. These days JavaScript gets m= ost of my time, but PHP will always be the language that got me into progra= mming=C2=A0professionally and for that I'll be eternally grateful.
=C2=A0

As = I understand the proposal, this would have no BC issues for code not in mod= ules. PHP could then set rules for code in modules that would not to be dir= ectly compatible with code outside modules.

=
That is the goal. Module code should be allowed to be different if the= optimization makes for faster running and easier to understand code (for t= he programmer, the IDE, and the parser itself). Changing things for the sak= e of changing them, no.
=C2=A0

At least to me this does not feel as big as trying= to implement unicode.

I would hope not= , because that turned out to be well night impossible.
=C2=A0

>=C2=A0 2. No ne= ed for autoloaders with modules; I assume this would be obvious, right?
= >
> Depends largely on whether modules can include and require to = get access to old code. I also didn't discuss how they behave - do they= share their variables with includes and requires?

I was presuming t= hat all old code would use autoloaders but modules would be free to do it a= better way.=C2=A0

If you need to call code from a namespace from inside a module, s= ure, the autoloader would be needed.

Th= is is correct and what I had in mind.
=C2=A0

> 6. Modules should be directorie= s, not .php files. Having each file be a module makes code org really hard.=
>
> Yes, but that is how JavaScript currently handles things. = It is currently necessary when making large packages to have an index.js th= at exports out the public members of the module. This entry point is config= urable through the package.json of the module.

I am envisioning that= there could be a module metadata file that would have everything that PHP = needs to handle the module.=C2=A0 It could even be binary, using protobufs:=

An interesting idea. I need to researc= h this some.=C2=A0


node_modules IMO is one of the worse things about the Jav= aScript ecosystem. Who has not seen the meme about node_modules being worse= than a black hole?

Fair enough. Or may= be import maps would be a better way forward.
=C2=A0

But ensuring that it is poss= ible to disallow loading needs to be contemplated in the design. PHP has to= be able to know what is a module and what isn't without expensive proc= esses.

One possible solution is that if= modules do not have <?php ?> tags, ever, and someone directly tries = to load a module through http(s) the file won't execute. Only files wit= h <?php ?> tags are executable by the web sapi.
=C2=A0

> 10. Having expo= rts separate from functions and classes seems like it would be problematic.=
>
> Again, this is how they work in JavaScript. Not saying tha= t's the best approach, but even if problematic it's a solved proble= m.

I have evidently not written enough JavaScript to realize that.

JavaScript is an odd prototypical duck.= =C2=A0 Everything ultimately is an object. Tha
=C2=A0

> I'm also intereste= d in learning on how other module systems out there do work.

I am ve= ry familiar with modules (packages) in GoLang and think PHP could benefit f= rom considering how they work, too.


I've only touched the surface on how GoLang does things. Some of it wa= s confusing to me at first. It's also been awhile so I'd need to re= fresh my memory to speak to it.
=C2=A0
> On Jun 27, 2024, at 3:22 PM, Michael Morr= is <tendoaki@gma= il.com> wrote:
> Composer would need a massive rewrite to be a= part of this since it currently requires the file once it determines it sh= ould do so. If we do a system where import causes the parser to act differe= ntly then that alone means imports can't be dealt with in the same mann= er as other autoloads.

That is why I am strongly recommending a mode= rn symbol resolution system within modules vs. autoloading.


Ok.
=C2=A0
>> I'm not fond of this either.
>=
> There will need to be a way to define the entrypoint php.=C2=A0 I = think index.php is reasonable, and if another entry point is desired it can= be called out -> "mypackage/myentry.php"

Why is an ent= ry point needed?=C2=A0 If there is a module metadata file as I am proposing= PHP can get all the information it needs from that file. Maybe that is the= `.phm` file?


Maybe. Again, I need = to look over this meta data=C2=A0format. Also, how does it get created?

=C2=A0
> On Jun 27, 2024, at 4:54 PM, Rob Landers <rob@bottled.co= des> wrote:
>> Thanks. The sticking point is what degree of cha= nge should be occurring. PHP isn't as behind an 8-ball as JavaScript is= since the dev can choose their PHP version and hence deprecation works mos= t of the time for getting rid of old stuff. But not always. Changes that ar= e incompatible with what came before need a way to do things the old way du= ring transition. Again, see PHP 6 and unicode, which snowballed until it wa= s clear that even if PHP 6 had been completed it wouldn't be able to ru= n most PHP 5 code.
>
> It=E2=80=99s not just up to the dev, but= the libraries we use and whether or not we can easily upgrade (or remove) = them to upgrade the php version.

By "upgrade" then, do you= mean convert them into modules, or just be able to use them as-is.=C2=A0
As I read it and am envisioning it, there would be no changes needed = to be able to use them as-is.


Any s= ystem that blocks existing code from being used would be a non-starter for = inclusion.
=C2=A0
> I think it would be a mistake to exclude old code and/or preve= nt templating. Not only are there now decades old code in some orgs, but ho= w would you write an email sender that sent templated emails, provide html,= generate code, etc? There has to be an output from the code to be useful.<= br>
Excluding old code or templates from modules would not exclude them = from working as they currently do outside modules.=C2=A0 As I see it, modul= es would be more about exporting classes and functions, not generating outp= ut per se.

So all that decades of old code could continue to exist o= utside modules, as it currently does today.


Exactly this.

=C2=A0
> I think it=E2=80=99s fine to use js= as an inspiration, but it isn=E2=80=99t the only one out there. There is s= ome precedent to consider directories as modules (go calls them =E2=80=9Cpa= ckages=E2=80=9D) and especially in PHP where namespaces (due to PSR-4 autol= oading) typically match directory structures.

Totally agree about in= spiration for modules outside JS, but not sure that PHP namespaces are the = best place to look for inspiration.=C2=A0

Namespaces by their very n= ature were designed to enable autoloading with a one-to-one file to class o= r interface, and by nature add conceptual scope and complexity to a project= that would not be required if a modern module/package system were added to= PHP.

Modules could and IMO should be a rethink that learns the less= ons other languages have learned over the past decade+.


Agreed.
=C2=A0
>> Node.js uses package.json and the attend= ant npm to do this sort of prep work.=C2=A0 And it's a critical part of= this since modules can be versioned, and different modules may need to run= different specific versions of other modules.
>
> Please, plea= se, please do not make a json file a configuration language. You can=E2=80= =99t comment in them, you can=E2=80=99t handle =E2=80=9Cif php version <= 9, load this, or if this extension is installed, use this.=E2=80=9D
>=
> Maybe that is desirable, but doing things slightly different based= on extensions loaded is def a thing.

I don't think commenting i= s important in this file, or even desired.

As I proposed above, thes= e could be protobuf or phar.=C2=A0 These should be build artifacts that can= be generated on the fly during development or for newbies even during depl= oyment, not hand-managed.

Hand manageme= nt has value in learning the underlying concepts though.
=C2=A0

I could see the g= eneration of two files; one in binary form and one that is readonly so a de= veloper can double-check what is in the current protobuf or phar file.
<= br>>> Those are implementation details a little further down the road= than we're ready for, I think.
>
> Personally, if these ar= e going to have any special syntax, we probably shouldn=E2=80=99t call them= .php files. Maybe .phm?

I was going to suggest that, and then remem= bered earlier PHP when there were multiple file extensions and that was a n= ightmare.=C2=A0

This does remind me to mention that I think there sh= ould be a required "module" declaration at the top of each file j= ust like Go requires a "package" declaration at the top of each f= ile. That would make it trivial for tooling to differentiate, even with gre= p

Fun idea, if the=C2=A0@ operator is ditch= ed as an error suppression=C2=A0operator it could be used as the package op= erator.=C2=A0 (If I manage to talk everyone into getting rid of one thing, = it's=C2=A0@).
=C2=A0
.
> the only thing I don=E2=80=99t like about this import/export thin= g is that it reminds me of the days when we had to carefully order our requ= ire_once directives to make sure files were loaded before they were used. S= o, I think it is worth thinking about how loading will work and whether loa= ding can be dynamic, hoisted out of function calls (like js), how order mat= ters, whether packages can enrich other packages (like doctrine packages) a= nd if so, how much they can gain access to internal state, etc. This is ver= y much not =E2=80=9Ca solved problem.=E2=80=9D

That is why I propose= d having a "compiled" module symbol table to eliminate most (all?= ) of those issues.

The more you bring i= t up, the more I am reminded of the import-map directive added to client-si= de JavaScript.

=C2=A0

> On Jun 27, 2024, at 6:00 PM, Rowan Tomm= ins [IMSoP] <i= msop.php@rwec.co.uk> wrote:
> I do think PHP badly needs a nat= ive concept of "module" or "package" - in fact, I'm= increasingly convinced it's the inevitable path we'll end up on at= some point. BUT I think any such concept needs to be built on top of what = we have right now. That means:
>
> - It should build on or work= in harmony with namespaces, not ignore or replace them

It may be an= unpopular opinion, but I would argue that namespaces were optimized for au= toloading and the one class/interface per file paradigm, not to mention to = regrettable choice of using the escape operator to seperate namespaces and = that fact that PHP throws away a lot of information about namespaces at run= time.

I remember when the choice to use= \ was made.=C2=A0 I've rarely been so angry about a language design ch= oice before or since.=C2=A0 I've gotten used to it, but seeing \\ all o= ver the place in strings is still.. yuck.
=C2=A0

IMO allowing modules to eventual= ly deprecate namespaces =E2=80=94 at least in a defacto form of deprecation= =E2=80=94 would allow modules to be much better than if the try to cling t= o a less desirable past.

> - It should be easy to take existing c= ode, and convert it to a module/package

Maybe, but not if that means= modules retain baggage that should really be jettisoned.

> and n= amespaces have proved an extremely successful way of sharing code without t= hose names colliding.

At the expense of a lot more complexity than n= ecessary, yes.

Managing symbols in a module need not be a hard probl= em if PHP recognizes modules internally rather than trying to munge everyth= ing into a global namespace like with namespaces.

=
I'm inclined to agree on these points, but I also don't = know the engine internals that wall.=C2=A0 Intuitively it would seem keepin= g the symbol table small would make the code go faster.
=C2=A0
> On Jun 27, 2024, = at 6:41 PM, Larry Garfield <larry@garfieldtech.com> wrote:
> What problem = would packages/modules/whatever be solving that isn't already adequatel= y solved?

Not speaking for Michael, obviously, but speaking for what= I envision:

1. Adding a module/package system to PHP with modern mo= dule features
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - including module private, mo= dule function, and module properties
2. Providing an alternative to auto= -loader-optimized namespaces.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 - better code = management and better page load performance


Couldn't have said it better myself.
=C2=A0
> Do we want:
>
= > 1. Packages and namespaces are synonymous?=C2=A0 (This is roughly how = JVM languages work, I believe.)
> 2. Packages and files are synonymou= s?=C2=A0 (This is how Python and Javascript work.)
> 3. All packages = correspond to a namespace, but not all namespaces are a package?

I w= ould argue packages (modules) should be orthogonal to namespaces to allow m= odules to be optimized for what other languages have learned about packages= /modules over the past decade+.

The fact that namespaces use the esc= ape character as a separator, that PHP does not keep track of namespace aft= er parsing is enough reason to move on from them, and that they were optimi= ze for one-to-one symbol to file autoload are enough reasons IMO to envisio= n a way to move on from them.

> And given the near-universality o= f PSR-4 file structure, what impact would each of those have in practice?= =C2=A0

Orthogonal.=C2=A0 Old way vs new way.=C2=A0 But still complet= ely usable, just not as modules without conversion.

The fact PSR-4 e= xists is an artifact of autoloading single-symbol files and thus a sunken c= ost does not mean that PHP should not cling to for modules just because the= y currently exist.


I have nothing t= o add to the above.=C2=A0

--000000000000dba69d061bede826--