Re: RFC: short and inner classes

On Fri, Mar 14, 2025, at 19:16, Bob Weinand wrote: > Hey Rob, > > On 6.3.2025 00:11:22, Rob Landers wrote: >> Hello PHP Internals, >> >> I'd like to introduce my RFC for discussion: >> https://wiki.php.net/rfc/short-and-inner-classes > A small note on the Reflection section: it should include a method giving you an array of all > contained ReflectionClasses: $reflection->getInnerClasses() > > And likely also a method to get an inner class by name > $reflection->getInnerClass("Foo"). > > > > Bob > Classes don't actually know their inner classes -- they aren't like properties. In essence, an inner class is just a regular class with a funny name and access to scopes it wouldn't normally have access to. We could probably add getOuterClass(): string if that is useful. It is possible to keep track of a class's inner classes, but then that introduces a paradox chicken/egg type problem during construction, which may or may not be a problem. On Fri, Mar 14, 2025, at 22:08, Rowan Tommins [IMSoP] wrote: > The other thing I wonder is whether the original reason why :: > wasn't > used as the namespace separator still applies, and needs to be accounted > for here? > > -- > Rowan Tommins > [IMSoP] > I'm replying to you Rowan, but also to the whole conversation on the topic of separating inner classes. I was going to add this example to the RFC: https://gist.github.com/withinboredom/c007e35d3b042b87b02ac550db589a0c, but I decided to get food poisoning for the last few hours instead. :joy: Where using it looks like this: $user = new User:>Builder("Rob")->withEmail("rob@bottled.codes")->build(); The user builder is intrinsically tied to the User class itself, it isn't just a namespace. The user builder shares scope with the user class and is able to be the only way to construct a user (barring reflection). So, I'm inclined to agree with Bob here: > Inner classes are supposed to be intrinsically tied to their containing class, and making it > work like a namespace reduces the association a lot. Furthermore, I'm relatively certain this approach can be slightly modified to support "namespace private/protected" classes, in general. So, that will also possibly be a follow-up RFC and having them mixed up will complicate things. In any case, I am not a fan of using the namespace separator here. I could get behind ::, but I feel that it introduces human ambiguity. I don't believe it would introduce compiler ambiguity, but as a human, I have to hope the programmers are using a style that makes it obvious what are inner classes and what are constants/methods. I don't know, I keep coming back to :> ... it isn't perfect, and it is somewhat annoying to type, but I don't have anything better. — Rob