On Wed, May 14, 2025, at 15:24, Michael Morris wrote: > > > On Wed, May 14, 2025 at 4:08 AM Rowan Tommins [IMSoP] <imsop....@rwec.co.uk> > wrote: >> __ >> >> What Michael Morris is talking about is really a completely different >> concept - it's more like "containers", in the sense of Docker, Kubernetes, >> etc, where different sections of code can be isolated, and declare classes >> with conflicting fully-qualified names. I don't think it's what most >> applications and libraries would want "modules" to be; it's probably best >> thought of as a completely separate feature. >> > > Well, it's what Go calls "modules". It's confusing because I was being > truthful, not snarky, when I said "Ask 10 programmers for the definition of > module and expect 12 answers." I'm self trained, so I expect to get my terms > wrong from time to time. But I know enough to identify problems and needs and > I've tried to be clear on that. > > I'm currently reading up on Phar and seeing exactly how suited it would be as > a foundation for a module system. I've also been reading on how go approaches > things, but go has package management baked into the compiler - PHP > outsources this to userland. I'm going to guess that's largely because of > lack of staff - PHP has no large backers (leeches like Facebook that use it > heavily and could back it yes, but not backers) and Go has Google. >
Hi Michael, Since it appears that nested classes probably won't pass by tomorrow (and thus no need to even touch short-syntax classes); I was going to focus on modules next. As I mentioned in that thread, the two are very closely related on a technical level -- it would have only taken 2-3 lines of changes to turn it into namespaces-as-modules and another 10 to turn it into proper modules (minus syntax support). However, I would implement it very differently knowing what I know today and with this as a goal (vs. nested classes). I have zero idea why people voted "no" and the people who expressed their reasons didn't entirely make sense either. So, I suspect it was just down to a poorly worded RFC and/or misunderstanding of how it worked. I'll have to revisit it again later. Sorry for the vent; that's not what this thread is about. Modules. First of all, I'd be more than happy to help with the implementation if you're up for some collaboration. Personally, here are my requirements I was going into it with: 1. Impossible name collisions. If you want to name something Foo\Bar in your module and I want to name something Foo\Bar in mine; we should be free to do so. Implementing this is straightforward. 2. Simple. I don't want to rely on a package manager to create modules or even use them. I really like the simplicity of "require_once" from time to time, and I don't want to see that go away. I have some ideas here, like `require_module my-module.php` 3. Easy to optimize. A module should be compiled as a complete unit so opcache (or the engine itself) can make full use of the context. There are a lot of optimizations left on the table right now because the engine dynamically compiles one file at a time. I haven't really even considered syntax too much; but I personally don't want anything new -- or at least, too "out there." I want it to feel like a natural extension to the language rather than something bolted on. I suspect there will need to be at least two new user-land elements to this: 1. a "module loader" that operates similar to the unified class loader Gina proposed. 2. importing modules and aliasing them (as needed). Would you be interested in collaborating further? — Rob
