Hi there On Fri, Feb 7, 2025 at 4:07 PM Tim Düsterhus <t...@bastelstu.be> wrote: > > I believe Ilija has some proof-of-concept regarding file-private > classes, which would sidestep the above problem of disambiguating static > member access.
Indeed. I shared a draft internally and responses were mixed. https://wiki.php.net/rfc/private-classes-and-functions https://github.com/php/php-src/compare/master...iluuu1994:php-src:private-classes The RFC proposes to allow declaring classes and functions as private, which will limit their usage to the current file, or more accurately, to the current namespace block (i.e. namespace {}, not namespace across files) The motivation is to allow declaring small helper classes (e.g. mocks for tests) in the file where they are used. Of course, this is currently already possible, but discouraged to preserve the ability to autoload classes. However, autoloading is not necessary for private members, so this concern goes away. Furthermore, private mangles the class/function name so that it doesn't conflict with other files declaring a class/function with the same private name. For example, multiple tests can create a private class DbMock without worrying about conflicts. To summarize, the main benefits for private is: * Single-use classes/functions live closer to their point of usage. * It signals to users that the members are not intended to be used outside the given file. * It avoids naming conflicts for cases between private members. The main pushback was that "private" does not sufficiently indicate the semantics of this feature. This could simply be solved with a different keyword. I guess for others, "namespace private" is a more interesting concept. One thing I disliked about the implementation is that private members still pollute the global symbol tables. That said, it's not likely to matter in practice. Anyway, I didn't have any immediate plans to pursue this RFC, so feel free to take over in any way you like. Ilija
