RFC: short and inner classes

> - I don't understand the use of `private` properties. Given that the > classes cannot have methods, they would be inaccessible, no?

> Hi > > Am 2025-03-06 07:23, schrieb Rob Landers: > > So, technically, they aren’t required to be in the same RFC; but also, > > they complement each other very well. > > They really should be separate RFCs then. Your RFC text acknowledges > that in the very first sentence: “two significant enhancements to the > language”. Each individual proposal likely has sufficient bike-shedding > potential on its own and discussion will likely get messy, because one > needs to closely follow which of the two proposals an argument relates > to.

> > As for the “Inner classes” proposal: > > - “abstract is not allowed as an inner class cannot be parent classes.” > - Why?

> - “type hint” - PHP does not have type hints, types are enforced. You > mean “Type declaration”.

> - “this allows you to redefine an inner class in a subclass, allowing > rich hierarchies” - The RFC does not specify if and how this interacts > with the LSP checks.

> Hi Rob > > Without looking too deep (yet) into the details, I'm generally in favor of the idea. > What I'm less in favor of is the implementation choice to expose the inner class as a property/const and using a fetch mode to grab it. > That feels quite weird to me honestly. How did you arrive at this choice? > > Kind regards > Niels

> 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.

> ## 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.

>> >> Closure::fromCallable('Outer::Inner::method'); > > You end up with: > > object(Closure)#1 (1) { > ["function"]=> > string(20) "Outer::Inner::method" > }

>> constant('Outer::Inner'); > > This returns: > > string(12) "Outer::Inner"

>> $inner = 'Inner'; >> Outer::{$inner}; > > This does nothing (but resolves to "Outer::Inner")

>> … and any other meta-programming functionality working on class >> constants or static methods. >> >> Also, what will happen for: >> >> class P { >> class Inner { } >> } >> >> class C extends P { >> const Inner = 'x'; >> } >> >> (and vice versa) > > This is a really good one. If for no other reason than I did a really poor job of explaining resolution(?) in the RFC. `P::Inner` belongs to `P`, not to `C`, so you can do `new C::Inner()` and it will resolve to `P::Inner()`:

> As with other static things in PHP, you can do some really strange things like this. This is similar to how you can redefine static constants in subclasses.

> Hi Bob > > On Thu, Mar 13, 2025 at 11:36 PM Bob Weinand <bobwei9@hotmail.com> wrote: > > > > On 6.3.2025 23:20:37, Ilija Tovilo wrote: > > > > > 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. > > > > Could you please elaborate on why the :: operator feels out of place? > > > > \ is a namespace separator. > > > > :: is a class scoping separator. > > > > > > You, yourself did decide to use nested :: for property hook scoping, like parent::$x::set() - a property scoped within a class, having methods. > > The same applies here - it's a class scoped within a class, having methods. > > > > Breaking from these patterns seems very surprising to me. > > :: is an operation performed on the class. E.g. fetch a static > property, fetch a constant, call a static method, while \ is part of > the class name. The way I see it, the outer class can simply add an > additional namespace component to the inner class. > > class Foo { > class Bar {} // Called Foo\Bar > > public Bar $bar; > } > > This is dead simple, it doesn't change any assumptions about class > names by embedding new symbols, it doesn't need a new operator, you > can refer to the class with its short name from inside the outer class > without `self:>`, which is shorter and more straight forward, `use > Foo\Bar;` will just work in other classes, etc. > > One thing this approach breaks is that it doesn't allow for > polymorphic inner class resolution, i.e. static:>Bar. But given this > was removed anyway, that point no longer applies. This can also easily > be replicated by a simple method: > > class Foo { > class Bar {} > > public function createBar(): Bar { > return new Bar(); > } > } > > Except this is actually type-safe, because the return value of > createBar() must stay compatible with Foo\Bar. > > Ilija >

> Hi Bob > > On Thu, Mar 13, 2025 at 11:36 PM Bob Weinand<bobwei9@hotmail.com> wrote: >> On 6.3.2025 23:20:37, Ilija Tovilo wrote: >> >>> 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. >> Could you please elaborate on why the :: operator feels out of place? >> >> \ is a namespace separator. >> >> :: is a class scoping separator. >> >> >> You, yourself did decide to use nested :: for property hook scoping, like parent::$x::set() - a property scoped within a class, having methods. >> The same applies here - it's a class scoped within a class, having methods. >> >> Breaking from these patterns seems very surprising to me. > :: is an operation performed on the class. E.g. fetch a static > property, fetch a constant, call a static method, while \ is part of > the class name. The way I see it, the outer class can simply add an > additional namespace component to the inner class.

> class Foo { > class Bar {} // Called Foo\Bar > > public Bar $bar; > } > > This is dead simple, it doesn't change any assumptions about class > names by embedding new symbols, it doesn't need a new operator, you > can refer to the class with its short name from inside the outer class > without `self:>`, which is shorter and more straight forward, `use > Foo\Bar;` will just work in other classes, etc.

> One thing this approach breaks is that it doesn't allow for > polymorphic inner class resolution, i.e. static:>Bar. But given this > was removed anyway, that point no longer applies. This can also easily > be replicated by a simple method: > > class Foo { > class Bar {} > > public function createBar(): Bar { > return new Bar(); > } > } > > Except this is actually type-safe, because the return value of > createBar() must stay compatible with Foo\Bar.

> Hi Rob > > On Thu, Mar 13, 2025 at 12:01 PM Tim Düsterhus <tim@bastelstu.be> wrote: > > > > Am 2025-03-12 11:10, schrieb Rob Landers: > > > - Accessing inner classes is done via a new token: ":>" instead of > > > "::". > > > > I don't particularly like that. It is “invented syntax” and I don't > > think that inner classes are sufficiently valuable to dedicate an entire > > operator to them > > I would like to echo these thoughts. I also think the RFC is kind of > missing the mark. Arguably the most common use-case for `@internal` is > to restrict a class to a specific package/module or namespace, > regardless of the user's class hierarchy. I believe you specifically > call this a non-goal: > > > Currently, many libraries implement “internal” classes by using a naming convention or an @internal annotation in the docblock. Inner classes enable libraries to define an internal class that cannot be used outside the class it is defined inside. This feature is not meant to be used as a “module” system, but rather as a way to encapsulate logic internal to a class, such as DTOs or helper classes. > > At least if I understand this statement correctly. > > In that case, I see much less value in nested classes. They might > still be ok if they are extremely simple, but the proposal is > currently quite complex. It has a custom operator, it deals with > shadowing, LSP, runtime resolution and more, in addition to visibility > which is the actual goal. Maybe more use-cases are enabled, but I > don't think they are currently well described. Assuming visibility can > partially be implemented in a simpler way (e.g. top-level, > file-private classes), the costs seem to outweigh the benefits in my > opinion. Hence I would not be in favor of the RFC in this or a similar > form. > > Ilija >

> the proposal is > currently quite complex.

> They might > still be ok if they are extremely simple

> to restrict a class to a specific package/module or namespace, > regardless of the user's class hierarchy. I believe you specifically > call this a non-goal:

> On Thu, Mar 13, 2025, at 12:01, Tim Düsterhus wrote: >> Hi >> >> Am 2025-03-12 11:10, schrieb Rob Landers: >> > - Accessing inner classes is done via a new token: ":>" instead of >> > "::". >> >> I don't particularly like that. It is “invented syntax” and I don't >> think that inner classes are sufficiently valuable to dedicate an entire >> operator to them that could serve a more useful purpose in the future. >> It also got 4 negative points in the rating back when the namespace >> separator was decided: https://wiki.php.net/rfc/namespaceseparator >> >> Would `\\` (i.e. two backslashes) work? The outer class for inner >> classes effectively act as a namespace, so it makes sense to me to use >> syntax that is similar to namespaces. >> >> I'll look into the rest when there is a new implementation, since I >> assume some details will still be clarified and fixed as part of >> implementing the proposal. >> >> Best regards >> Tim Düsterhus >> > > I am not particularly attached to the separator. I specifically chose > it due to being a mixture of :: and -> and -: seemed like a bad idea. > In other words, an inner class felt natural to use :> -- however, I > have some issues with it myself. Particularly, it is too much like |> > and as shown in the namespace RFC, way too easy to typo. Personally, > after using it for a few days, I'd almost rather go back to :: ... > > I will give \\ a try, but it has to be typed quite a bit when > referencing inner classes, so keeping it easy to type is a must. I > feel like \\ requires a large movement to type, at least on a qwerty > non-english keyboard. Maybe people using other keyboards can chime in.

>> I don't think that inner classes are sufficiently valuable > > I'm curious why some people feel this way and why some other people > are saying the opposite (emphatically). I'll nudge the private emails > I've received to speak up publicly on the list as well. But, why do > you feel this way?

> I will give \\ a try, but it has to be typed quite a bit when > referencing inner classes, so keeping it easy to type is a must. I feel > like \\ requires a large movement to type, at least on a qwerty > non-english keyboard. Maybe people using other keyboards can chime in.

>> I don't think that inner classes are sufficiently valuable > > I'm curious why some people feel this way and why some other people are > saying the opposite (emphatically). I'll nudge the private emails I've > received to speak up publicly on the list as well. But, why do you feel > this way?

>On Sun, Mar 23, 2025 at 5:20 PM Larry Garfield <larry@garfieldtech.com> >wrote: > >> >> So, how would nested classes compare to fileprivate, in terms of ability >> to solve the problem space? As I understand it, the goal is: >> >> 1. Classes that can be instantiated only by the class that uses them. >> 2. But can be returned from that class to a caller and reused as >> appropriate. >> > > >I think the one other difference is that nested classes can access private >variables or their outer classes.

> Private access restricts the use of an entity to the enclosing declaration, and to extensions of that declaration that are in the same file.

> Le 15 mars 2025 à 12:53, Rowan Tommins [IMSoP] <imsop.php@rwec.co.uk> a écrit : > > > > On 14 March 2025 23:37:08 GMT, Rob Landers <rob@bottled.codes> wrote: >> 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. > > As far as I can see, all four languages I looked up last night (Java, C#, Swift, Kotlin) use the same syntax for accessing a nested type as for accessing a property or method, so we'd be following the crowd to use "::" > > That said, I think they all also use that same syntax for namespace (or equivalent) lookups, so the same argument can be made for "\". (Why PHP separates those isn't entirely clear to me.) >

> > > On 14 March 2025 23:37:08 GMT, Rob Landers <rob@bottled.codes> wrote: > >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. > > As far as I can see, all four languages I looked up last night (Java, C#, Swift, Kotlin) use the same syntax for accessing a nested type as for accessing a property or method, so we'd be following the crowd to use "::" > > That said, I think they all also use that same syntax for namespace (or equivalent) lookups, so the same argument can be made for "\". (Why PHP separates those isn't entirely clear to me.) > > Having some new syntax makes them feel more "exotic" to me. The C# and Swift docs give the impression that nesting types is "just something that can happen", rather than a whole new language concept to learn. > > Java's "inner classes" are something different, and I think we should avoid using that term. > > > > > 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. > > To me namespace, module, or file visibility seem like much more natural additions to the language, and to solve most of the same problems as nesting types. > > I guess a public nested class is a bit like a "friend class"? In that it has special access to its surrounding class, but otherwise might as well just be sharing a namespace with it. But it's also necessarily in the same file, so marking those members "file private" rather than "private" would also allow that. > > A private nested class can only be explicitly mentioned within that narrow context, which again feels very much equivalent to "file private". > > > > $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). > > If we had either file or namespace visibility, exactly the same thing could be achieved with those, and would look like this: > > $user = new User\Builder("Rob")->withEmail("rob@bottled.codes")->build(); > > The "User" class would have a "file private" or "namespace private" constructor, callable from the "User\Builder" class but not elsewhere; the build() method would return the "User" instance. > > > > I think I'm coming to the conclusion that we should use backslash: nested types can be viewed as a shorthand way of having a class and namespace with the same name, plus applying some visibility rules to that namespace. > > Rowan Tommins > [IMSoP] >

>I have not grasped any single argument in favour of \, except "other languages are doing it too", "existing tooling splitting on backslash would continue to work" and "we could use the existing use statement as is".

> All right, but apart from the sanitation, medicine, education, wine, public order, irrigation, roads, the fresh water system and public health, what have the Romans ever done for us?

>Also, just because other languages are doing a mistake, it does not mean we have to repeat it. They are generally doing it because their identifier separator is universal and it's consistent. It does not mean that it's without its own problems.

>Using the double colon is a very minor BC break (accessing a class by a class constant value?! That's also quite inconsistent that it works at all, as you can't do that with normal constants, only class constants.). >Using another sigil would also be possible (like :>). But for the backslash I only see drawbacks. > >Also, nothing precludes us from allowing "use Foo\Bar::Inner;".

> Hey Rob, > > On 17.3.2025 17:53:26, Rob Landers wrote: >> On Mon, Mar 17, 2025, at 16:30, fennic log wrote: >>> 2. As with any syntax change and new operator there needs to be very careful consideration, do we need a new operation, or could `::` if the parent is static or `->` if the class is initialized? >> >> There's quite a long thread already about this very topic. That being said, the inner class has no bearing on whether the outer class is instantiated or not. Originally, I used `::` as the separator, but it seems there are some good arguments for `\`, so we will see. > I have not grasped any single argument in favour of \, except "other languages are doing it too", "existing tooling splitting on backslash would continue to work" and "we could use the existing use statement as is". > > > The problems are numerous though: > 1. Unlike other languages (e.g. C# and java), namespaces and classes may share a name in PHP. E.g. class "Y" in a namespace "X" and class "X" may not exist both. In PHP that's allowed. Inner classes compete with namespaced classes for their fully qualified name. > 2. Autoloading will have to become aware of inner classes. > 3. Autoloading will have to do a non-cacheable check for existence on the inner class, before iteratively testing whether any parent has a respective .php file. Currently autoloading takes a class name, transforms it to a single canonical path, and includes it. Always succeeding. > 4. Humans, navigating to a path, will not be able to navigate to a file directly but have to search for it. > 5. Tooling splitting on backslash might assume the 1:1 mapping to the filesystem and break. It's really not a catch all. Some things may be broken and some not, but all need to be probably revisited anyway. > 6. It makes accessing via parent, self or static weird. These keywords have always been followed by a double colon. (Even if this particular RFC does not end up adding them) And it will conflict with a namespace named "parent" for example. > 7. At least right now, every backslash identified symbol is trivially universally public. With \ as an inner class separator, this would no longer be the case. Maybe that will eventually change, but today this can be relied upon. > > Also, just because other languages are doing a mistake, it does not mean we have to repeat it. They are generally doing it because their identifier separator is universal and it's consistent. It does not mean that it's without its own problems. > > > Using the double colon is a very minor BC break (accessing a class by a class constant value?! That's also quite inconsistent that it works at all, as you can't do that with normal constants, only class constants.). > Using another sigil would also be possible (like :>). But for the backslash I only see drawbacks. > > Also, nothing precludes us from allowing "use Foo\Bar::Inner;". > > > >>> 3. The idea that extending the parent class doesnt no inherit the child classes doesnt make sense to me. >>> As then if you extend a parent class and call a function of that class which could rely on the existence of an inner class, I can see a lot of headaches caused by this exact scenario. >>> As a developer, if I extend a class, I expect the entire dependance of that class to be inherited, otherwise the extending class won't work. >> >> I'm not sure what you mean. When you inherit a class, you do not necessarily inherit everything from its superclass. You are free to override it however you want. Since we are defining "types" in the sense of PHP, we cannot merely inherit a "type", otherwise we would cause all kinds of issues with LSP. This is specifically why inheritance works the way it does in this RFC and why `static::` is forbidden. > I don't understand the problem here. > > > for each nested class in parent class: > class_alias(substitute parent class with child class in class name, class name) > > Very simple. There's no magic needed, it can be simply class aliases. This will also make static, self and parent trivially work. >

> On 15.3.2025 00:37:08, Rob Landers wrote: > > > >> 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. >> > > > I don't see the chicken-and-egg problem here. You can simply collect all the inner class names at compilation. You don't even need to actually store the zend_class_entry - just collect the names and fetch from the class table at runtime (and ignore missing ones, e.g. if there was an error during linking). >