On Wed, Mar 5, 2025, at 5:11 PM, Rob Landers wrote: > Hello PHP Internals, > > I'd like to introduce my RFC for discussion: > https://wiki.php.net/rfc/short-and-inner-classes
I agree with others who have said this should be two RFCs. They stand alone, but can complement each other well. That's fine, talk about how that works, but they're separate RFCs. (Like we split hooks and aviz.) I'm broadly in favor of short classes and warm on inner classes, with assorted caveats as below. ## Short classes The no-method-definitions restriction seems odd to me. I don't really see what value that provides. The main advantages are 1. Even shorter way to define promoted properties for the common case. 2. No need to define a body if you don't need one. Neither of those conflicts with defining methods. If the concern is the verbosity of method definitions, well, I tried: https://wiki.php.net/rfc/short-functions I still think that would be beneficial, but am frying other fish at the moment. So really, all it need to do is allow inline definition of the properties by the class name as an alternative to a constructor. class Point(int $x, int $y) {} class Rect(Point $tl, Point $br) { public method area() { /* ... */ } } (Also allowing to skip the empty {} is fine with me, but that the last of my concerns.) The other question is trait usage. The RFC proposes just shifting that up to the declaration line. That also seems fine to do either way, regardless of whether there are methods. My biggest concern with this is that it makes methods and short-classes mutually incompatible. So if you have a class that uses short-syntax, and as it evolves you realize it needs one method, sucks to be you, now you have to rewrite basically the whole class to a long-form constructor. That sucks even more than rewriting a short-lambda arrow function to a long-form closure, except without the justification of capture semantics. Additionally: The RFC doesn't specify if or how properties with hooks are supported. That should be defined so we can argue about it. :-) Additionally: What happens here: class Point(int $x, int $y); class 3DPoint(int $z) extends Point; I have to redeclare all of the parameters from the parent, just to add one? That's ugly. ## Inner classes I'm on board with the use case. What I'm not sure on is inner classes vs file-private visibility, something that Ilija was working on at one point and Michał Brzuchalski suggested in his post. Both solve largely the same problem with different spelling. Arguably, inner classes have fewer issues with current autoload conventions. I must ponder this further. > However, no classes may not inherit from inner classes, but inner classes may > inherit from other classes, including the outer class. I think you have one too many negatives in that sentence. --Larry Garfield
