Hi Rob On Thu, Mar 6, 2025 at 12:14 AM Rob Landers <rob@bottled.codes> wrote: > > I'd like to introduce my RFC for discussion: > https://wiki.php.net/rfc/short-and-inner-classes
Thank you for your proposal. I'm very much against the idea of introducing yet another slightly shorter form to declare a class. In your examples (they have been removed in the meantime), it's unclear how the syntax interacts with inherited constructors, trait-used constructors, whether repetition of readonly parent properties leads to a "Cannot modify readonly property" error, etc. The concept of visibility for classes does seem useful to me. Some questions that crossed my mind when reading the proposal: > Inner classes may only be nested one level deep, may not be a parent class, > and may not be declared abstract These restrictions seem somewhat arbitrary. For example, you may want a private class to extend another private class, creating some local class hierarchy. I think there's value in relaxing this restriction, if technically possible. > PHP Fatal error: Private inner class Box::Point cannot be used in the global > scope How is this implemented? I presume using a public nested class as type hints should be allowed, but these classes may not be loaded when the function is declared. We implement delayed variance checks for methods, which do trigger the autoloader, but functions do not (since they cannot violate variance rules). > Visibility Rules: Private and protected inner classes are only instantiable > within their outer class (or subclasses for protected) and cannot be used as > type declarations outside their outer class. This encapsulation ensures that > the inner class’s implementation details remain within their intended scope. This introduces a weird case where methods with parameter or return types referring to private classes may not be redeclared in their subclasses, given that the type cannot be specified, even if the methods themselves are not private or final. You do mention something very similar in your e-mail with the __constructor case, but I really fail to see how this provides any benefit. I would also like to echo what has been said about the :: operator, which feels out of place. I understand that \ comes with additional autoloading challenges, namely requiring a fallback autoloading strategy that currently does not conform to PSR-4. Disclaimer: I have not looked at the implementation at all yet. Ilija
