Re: Two-step creation for PHP modules

On 13 June 2026 11:31:43 BST, "Alex "Pierstoval" Rock" <pierstoval@gmail.com> wrote: In my opinion this ... > So yeah, "it's private so you can't test it" still has to apply, as said, > just like you shouldn't test your private class methods (even though PHP allows it with hacks). .. doesn't match this: >1. Allowing internal code units, not exposed to the outside of a package or module, but >accessible from within it. >   This is for maintainers to have a much easier way to define non-BC-covered code. Just because a piece of functionality is internal to the library, doesn't mean it shouldn't be covered by unit tests. Indeed that's almost the definition of a unit test vs an integration test, if the library only exposes a narrow interface; and "refactor into a separate helper" is a common answer to "I want to unit test a private method". Meanwhile this ... >3. Allowing multiple modules with same names to be loaded at the same time, as long as they are >different files. .. basically answers this: >Containers as "code block that's executed in another thread" seems like something >completely different than implementing modules, or am I missing something? In order to reuse code written assuming a class name is unique (which is every line of PHP currently in existence) you need to define a boundary where code "inside" runs without affecting the code "outside", except through a specific interface. Whether that would literally be two separate threads, I'm not sure, but it certainly has a lot in common. And yes, that is completely different from "modules" as units of scope. It needs to affect the *public* parts of a module, as well as the *private* parts; and it needs to affect *a group of modules* which rely on each other, not each in isolation. Rowan Tommins [IMSoP]