[PHP-DEV] RFC: short and inner classes

[ilutov]

Hi Rob

On Thu, Mar 13, 2025 at 1:57 PM Rob Landers <rob@bottled.codes> wrote:

> the proposal is
> currently quite complex.

Most of this is just describing how classes work already and going in-depth on where there may be confusion -- there are no significant changes to how classes actually work. The actual changes to the engine are basically just visibility rules, some syntax changes (to allow nesting `class` inside another class), and handling the new operator. The hard part is explaining how classes work, because they don't really have a defined behavior. In other words, I cannot just say "the way this works doesn't change anything."

Well, you cut out the examples I gave:

It has a custom operator, it deals with shadowing, LSP, runtime resolution and more, in addition to visibility which is the actual goal. Those are unrelated to existing behavior, they are introduced in the proposal.

* The custom operator and runtime resolution is not something that
technically needs to be there. The name of class Foo { class Bar {} }
could simply be Foo\Bar. I've mentioned before that this does not work
with PSR-4, but there's no reason it can't work with autoloading at
all. An extended autoloading spec could recursively search
Foo/Bar/Baz.php, then Foo/Bar.php, and so forth. Given this happens
only when loading the class, and nesting would usually be limited in
quantity and amount, that seems like a reasonable solution, and
Composers optimized autoloader could avoid it entirely. This would
also solve the same issue for sealed classes, assuming they're named
in a similar fashion.

* By shadowing I referred to static:>MyClass. This makes it more
modular, but it's also another layer of complexity and indirection.
You haven't really provided a reasoning and examples of how this could
be used. It's also not clear if this can be prevented. The inner class
can be marked as final, but that wouldn't stop you from shadowing the
inner class without extending it. Similarly, static:>MyClass would
have no type guarantees, given that it can be shadowed by any classes,
not just classes that are compatible.

class Outer {
    protected class Inner {
        public static function innerTest() {}
    }

    public static function outerTest() {
        static:>Inner::innerTest();
    }
}

class OuterV2 extends Outer {
    protected class Inner {} // This breaks outerTest()
}

* LSP issues have been mentioned before. You can use self:>Inner in
method signatures even if the inner classes are private. The method
could be called from sub-classes, but they couldn't ever override it,
since there's no way to satisfy the parent signature. This makes it
implicitly final. Not technically a problem, just odd.

As mentioned, maybe there are additional use-cases this complexity can
cover, but the RFC doesn't give many examples. If the primary reason
for this complexity is just visibility, then I don't think this is the
simplest and best way in which that goal could be achieved.

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

And now you can understand why they WERE just simple classes (short classes). So, you can see why I originally bundled them together because of this EXACT argument. :sigh:

The arguments above are not limited to complex classes. Simple classes
would apply to.

* The :> operator is still something new that I don't believe needs to be there.
* Shadowing simple classes can still cause incompatibilities between
constructors.
* The LSP issue applies.
* As soon as we try to add support for complex classes, we'll run into
the same questions again. Thinking ahead is always worth it, to
prevent us from running into issues later. Doesn't mean everything
needs to land at the same time ofc.

Ilija

[Rob_Landers]

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?

— Rob

[Rob_Landers]

On Thu, Mar 13, 2025, at 21:41, Ilija Tovilo wrote:

Hi Rob

On Thu, Mar 13, 2025 at 1:57 PM Rob Landers <rob@bottled.codes> wrote:

the proposal is

currently quite complex.

Most of this is just describing how classes work already and going in-depth on where there may be confusion – there are no significant changes to how classes actually work. The actual changes to the engine are basically just visibility rules, some syntax changes (to allow nesting class inside another class), and handling the new operator. The hard part is explaining how classes work, because they don’t really have a defined behavior. In other words, I cannot just say “the way this works doesn’t change anything.”

Well, you cut out the examples I gave:

Ahh, ok. FWIW, I only cut out your examples to shorten the email. But I see what you mean here. I think I can word the RFC in such a way as to make it so I don’t have to specify how classes work along with how inner classes work… I’ll have to think about it. Maybe I can just explain more about how it actually works? I’m not sure. I’ll probably look at the enums RFC to get a better idea of how to do this.

For example, I can explain that an inner class is basically a class with a special name and special scopes attached. Then I can simply explain how these special scopes interact with the rest of the language. Then I can get around defining class-like behaviors, and it may even be easier to reason about.

It has a custom operator, it deals with shadowing, LSP, runtime resolution and more, in addition to visibility which is the actual goal. Those are unrelated to existing behavior, they are introduced in the proposal.

• The custom operator and runtime resolution is not something that

technically needs to be there. The name of class Foo { class Bar {} }

could simply be Foo\Bar. I’ve mentioned before that this does not work

with PSR-4, but there’s no reason it can’t work with autoloading at

all. An extended autoloading spec could recursively search

Foo/Bar/Baz.php, then Foo/Bar.php, and so forth. Given this happens

only when loading the class, and nesting would usually be limited in

quantity and amount, that seems like a reasonable solution, and

Composers optimized autoloader could avoid it entirely. This would

also solve the same issue for sealed classes, assuming they’re named

in a similar fashion.

I disagree completely. If you recall, last year, I tried to pass function autoloading (which would have helped with records) and people really, really, really didn’t want to have to change how autoloading worked (and I’m not talking about the list – I mean projects). So, suggesting a change to autoloading is probably a non-starter.

That being said, I don’t hate it either.

• By shadowing I referred to static:>MyClass. This makes it more

modular, but it’s also another layer of complexity and indirection.

You haven’t really provided a reasoning and examples of how this could

be used. It’s also not clear if this can be prevented. The inner class

can be marked as final, but that wouldn’t stop you from shadowing the

inner class without extending it. Similarly, static:>MyClass would

have no type guarantees, given that it can be shadowed by any classes,

not just classes that are compatible.

class Outer {

protected class Inner {

public static function innerTest() {}

}

public static function outerTest() {

static:>Inner::innerTest();

}

}

class OuterV2 extends Outer {

protected class Inner {} // This breaks outerTest()

}

static is expressly forbidden with inner classes after Tim pointed out that it basically breaks LSP. It doesn’t, technically, but it makes it hard to reason about for the exact example you gave.

One thing worth pointing out here, though, is that in your example you have Outer:>Inner and OuterV2:>Inner. These are two completely distinct classes. They are not related to each other at all.

• LSP issues have been mentioned before. You can use self:>Inner in

method signatures even if the inner classes are private. The method

could be called from sub-classes, but they couldn’t ever override it,

since there’s no way to satisfy the parent signature. This makes it

implicitly final. Not technically a problem, just odd.

This is not the case any more. If you have a private inner class, you cannot use it as a type declaration on a protected/public method, property, or static member. A private class can still be returned and passed around once instantiated, and it can implement an interface/base class (or not). This is very similar to C# or Java.

For example, this is ok:

interface Shape {}

class ShapeFactory {

private class Rect implements Shape {}

public function makeRect()): Shape { return new ShapeFactory:>Rect(); }

}

But this is not:

class ShapeFactory {

private class Rect {}

// Private inner class ShapeFactory::Rect cannot be used as a return type for public methods

public function makeRect()): ShapeFactory:>Rect { return new ShapeFactory:>Rect(); }

}

As mentioned, maybe there are additional use-cases this complexity can

cover, but the RFC doesn’t give many examples. If the primary reason

for this complexity is just visibility, then I don’t think this is the

simplest and best way in which that goal could be achieved.

I’ll add some more realistic examples to the RFC.

They might

still be ok if they are extremely simple

And now you can understand why they WERE just simple classes (short classes). So, you can see why I originally bundled them together because of this EXACT argument. :sigh:

The arguments above are not limited to complex classes. Simple classes

would apply to.

• The :> operator is still something new that I don’t believe needs to be there.

• Shadowing simple classes can still cause incompatibilities between

constructors.

• The LSP issue applies.

• As soon as we try to add support for complex classes, we’ll run into

the same questions again. Thinking ahead is always worth it, to

prevent us from running into issues later. Doesn’t mean everything

needs to land at the same time ofc.

Ilija

— Rob

[Bob_Weinand]

Hey Rob,

···

On 13.3.2025 21:46:49, Rob Landers wrote:

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.

Please go back to ::. The double colon was perfectly fine, the only thing which was weird was the implicit constant. It’s fine for constants and inner classes to share the same name scoping (i.e. a constant must not share a name with an inner class). But an inner class should not be an actual constant.

But otherwise, this was perfectly fine.

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 don’t know why some people feel this way, but at least with the autoloading mechanisms we have in PHP there are definite limitations to multiple classes in one file:

• If you deserialize your data structure and it contains another class, whose name does not match the file name, you better hope to god that it has been autoloaded already. Surprising failures in production follow. (e.g.: the amphp\parallel process runner will try to serialize your exception. That’s fine. But as soon as it’s accidentally bubbling up and as it’s not autoloadable, the hell breaks loose.)
• Enums or Data Transfer objects specific to one or multiple functions of only this specific class would naturally fit into the same file. But you can’t do it … because the autoloading might try to load the enum first, before the class whose constructor or function you want to call is actually loaded.
• Now, if you actually stuff multiple classes / enums into a single file, it’s non-trivial to figure out (as the human reader, but obviously for the autoloader too) which file to access to read up the definition of a specific enum (short of using dedicated tooling for it).

Certainly, one may say - yeah, just religiously use different files for … every … single … class.
But what’s the point of that dogma?
It definitely doesn’t help the organization of dedicated helper structures tied to a single class.
It’s a tool for organization. It’s not complex to understand.

Outside of very puristic arguments I don’t see any reason why one would not want inner classes.

Further, with short classes, should they hopefully be introduced as well, it will become trivial to write shapes for any internal datastructures - simply using a “class Point(int $x, int $y); private Point $pos;” rather than “/** @var list{int, int} */ private array $pos;”.
This will be a very ergonomic way to reduce ad-hoc arrays which are only typehinted by phpdoc, giving proper typing and also safe access to structures via named accessors rather than [0] and [1] etc.

Further Questions on the (original) RFC:

• Why is there a conflict in static properties and the inner class name? The former always has a leading $ sigil.

• Any particular reason to disallow abstract inner classes? Feels arbitrary.

And a note: I consider the inheritance example misguided as “static constructors” (static methods which invoke new()) would be a better pattern here. Could you maybe come up with another example here?

Bob

[Bob_Weinand]

Hey Ilija,

···

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.

Bob

[Rob_Landers]

On Thu, Mar 13, 2025, at 23:26, Bob Weinand wrote:

Hey Rob,

On 13.3.2025 21:46:49, Rob Landers wrote:

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.

Please go back to ::. The double colon was perfectly fine, the only thing which was weird was the implicit constant. It’s fine for constants and inner classes to share the same name scoping (i.e. a constant must not share a name with an inner class). But an inner class should not be an actual constant.

But otherwise, this was perfectly fine.

My biggest issue with :: is that it gets weird:

class Foo {

public class Bar {}

public const Bar = “”;

public static function Bar() {}

}

echo Foo::Bar; // this is the constant

new Foo::Bar(); // this is the class

Foo::Bar(); // this is the method

new (Foo::Bar()); // this is the method

new (Foo::Bar); // this is constant

I can now differentiate between these all in the AST, but it seems weird to me. If we go this route, I’d personally have the preference to allow them all and let people’s code-style dictate what is acceptable or not – assuming I can ensure there is no ambiguity in the grammar. At least with :> (or something else) we don’t have to even have that discussion.

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 don’t know why some people feel this way, but at least with the autoloading mechanisms we have in PHP there are definite limitations to multiple classes in one file:

• If you deserialize your data structure and it contains another class, whose name does not match the file name, you better hope to god that it has been autoloaded already. Surprising failures in production follow. (e.g.: the amphp\parallel process runner will try to serialize your exception. That’s fine. But as soon as it’s accidentally bubbling up and as it’s not autoloadable, the hell breaks loose.)

• Enums or Data Transfer objects specific to one or multiple functions of only this specific class would naturally fit into the same file. But you can’t do it … because the autoloading might try to load the enum first, before the class whose constructor or function you want to call is actually loaded.

• Now, if you actually stuff multiple classes / enums into a single file, it’s non-trivial to figure out (as the human reader, but obviously for the autoloader too) which file to access to read up the definition of a specific enum (short of using dedicated tooling for it).

Certainly, one may say - yeah, just religiously use different files for … every … single … class.

But what’s the point of that dogma?

It definitely doesn’t help the organization of dedicated helper structures tied to a single class.

It’s a tool for organization. It’s not complex to understand.

Outside of very puristic arguments I don’t see any reason why one would not want inner classes.

Further, with short classes, should they hopefully be introduced as well, it will become trivial to write shapes for any internal datastructures - simply using a “class Point(int $x, int $y); private Point $pos;” rather than “/** @var list{int, int} */ private array $pos;”.

This will be a very ergonomic way to reduce ad-hoc arrays which are only typehinted by phpdoc, giving proper typing and also safe access to structures via named accessors rather than [0] and [1] etc.

Further Questions on the (original) RFC:

• Why is there a conflict in static properties and the inner class name? The former always has a leading $ sigil.

Funny enough, this was due to me messing up the AST such that it was trying to access a property instead of a constant. Once I fixed that, the conflict went away.

• Any particular reason to disallow abstract inner classes? Feels arbitrary.

This went away as well, once I started cleaning up the grammar. Basically, I couldn’t work out how to allow :: in extends. I eventually figured it out once I implemented :>. Replacing :> with virtually anything else is quite possible – including going back to :: (I think).

And a note: I consider the inheritance example misguided as “static constructors” (static methods which invoke new()) would be a better pattern here. Could you maybe come up with another example here?

Bob

That was a pretty bad example! It illustrated the point but would probably be a bad practice.

— Rob

[Bob_Weinand]

Hey Rob,

···

On 14.3.2025 00:26:03, Rob Landers wrote:

My biggest issue with :: is that it gets weird:

class Foo {

public class Bar {}

public const Bar = “”;

public static function Bar() {}

}

echo Foo::Bar; // this is the constant

new Foo::Bar(); // this is the class

Foo::Bar(); // this is the method

new (Foo::Bar()); // this is the method

new (Foo::Bar); // this is constant

I can now differentiate between these all in the AST, but it seems weird to me. If we go this route, I’d personally have the preference to allow them all and let people’s code-style dictate what is acceptable or not – assuming I can ensure there is no ambiguity in the grammar. At least with :> (or something else) we don’t have to even have that discussion.

Why would that be weird?

In 99% of the cases new followed by something followed by double colons followed by something else is just the inner class.

Writing new (Foo::Bar) or new (Foo::Bar()) already today looks suspicious and will remain looking suspicious. Nothing will change about that. And “Foo::Bar” (or “Foo::Bar()”) without being preceded by “new” or followed by “::” is just the normal class constant.

On top of that, there are naming conventions in PHP which will make it even more obvious: class constants in uppercase and methods in camelCase and class names in PascalCase. So, just looking at Foo::Bar (without considering any surrounding tokens), you expect a class name. Looking at Foo::BAR, you expect a constant. Looking at Foo::bar you expect a method.

echo Foo::BAR; // this is the constant

new Foo::Bar(); // this is the class

Foo::bar(); // this is the method

new (Foo::bar()); // this is the method

new (Foo::BAR); // this is constant
// or alternatively:
$myFantasticInterface = Foo::bar();

new $myFantasticInterface;
$myAwesomeInterface = Foo::BAR;
new $myAwesomeInterface;

There’s no real surprises at a glance as long as you don’t intentionally make your code obscure.

Bob

[Tim_Dusterhus]

Hi

Am 2025-03-13 21:46, schrieb Rob Landers:

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'm using a German keyboard where the backslash is indeed not particularly convenient to type, but that already applies to regular classes / namespaces. Once I reach out to type the backslash, the number of backslashes I type doesn't particularly matter, so I don't follow how typing would be any more complicated than regular class names.

The double backslash has one notable drawback in strings, where it would blow up to four backslashes in a row, but with the `::class` syntax and first class callables, putting class-names in strings should hopefully be rare going forward.

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?

You cut the context from the part you quoted, so I'm not sure how to answer to that question, since it seems to be based on a false premise.

Best regards
Tim Düsterhus

[Tim_Dusterhus]

Hi

Am 2025-03-14 01:22, schrieb Bob Weinand:

[…] class constants in uppercase […]

enum cases are a notable Exception. They also use PascalCase (both internal enums and the PER-CS coding style as published by PHP-FIG).

But that's also a good question for the RFC author: Is defining inner classes within an enum legal? The RFC says that inner enums are future scope, but what about “outer” enums? The specification in the “Usage” section is not entirely clear to me.

Best regards
Tim Düsterhus

[ilutov]

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

[Rob_Landers]

On Fri, Mar 14, 2025, at 17:09, Ilija Tovilo wrote:

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 Ilija,

What about a hybrid approach? Maybe something like \\ that Tim suggested? But hear me out. Instead of it being between all inner parts, it is only between the outermost and inner parts of the class, otherwise just use \. This also solves a problem where:

• we don’t need to change anything with autoloading

• we can differentiate between different types with the same name

So

namespace Foo;

class Outer {

class Middle {

class Inner {}

}

}

namespace Foo\Outer;

class Middle {

}

can be differentiated from each other (Foo\Outer\Middle vs. Foo\Outer\Middle\Inner).

I also like the idea of just using the name instead of having Foo:>Bar… I think that is possible now that I have all the machinery in place for visibility. I may have the implementation ready today/tomorrow (as per the currently written RFC).

— Rob

[Bob_Weinand]

Hey Ilija,

···

On 14.3.2025 17:09:40, Ilija Tovilo wrote:

Hi Bob

On Thu, Mar 13, 2025 at 11:36 PM Bob Weinand [<bobwei9@hotmail.com>](mailto: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.

I’d consider this a very internals perspective. Yes, internally it will include its separator and the reported name includes the separator.

From a user perspective, the class is fetched (an operation!) from its defining class.

Similarly, static::Foo (if it is going to be re-introduced) and parent::Foo, are definitely fetches of the class.

And as such, it should also have the :: operator.

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.

use Foo\Bar; to reference to an inner-class sounds very much like a bad idea to me.

Inner classes are supposed to be intrinsically tied to their containing class, and making it work like a namespace reduces the association a lot.

I desire explicitness, which a different symbol can give you. Using namespace-syntax makes the autoloading and human resolution more complex for no gain.

Removing the self:: seems enticing, but it breaks at the moment you add inheritance. Then you’ll have to either make it a binding-time decision whether it’s a namespace access or a parent inner class access.

class Foo { class Bar {} } class Baz extends Foo { public Bar $bar; // ??? parent::Bar would be obvious. }

Certainly you could opt for only removing self:: in classes they are declared in, but what’s then the syntax when referring to an inner class up the inheritance chain? parent\Foo? That’s plain weird. Or explicitly requiring the concrete class name the inner class is implemented on? Then this becomes the only weird case which cannot be accessed through the scope resolution. Why would one want that?

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.

I don’t care much about static resolution for this, but self:: and parent:: are relevant.

Bob

[Bob_Weinand]

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

[Rob_Landers]

On Wed, Mar 12, 2025, at 11:10, Rob Landers wrote:

On Thu, Mar 6, 2025, at 00:11, Rob Landers wrote:

Hello PHP Internals,

I’d like to introduce my RFC for discussion: https://wiki.php.net/rfc/short-and-inner-classes

This RFC defines a short class syntax as well as the ability to nest classes inside another class. This introduces an unprecedented amount of control, flexibility, and expressiveness over how objects are used and instantiated in PHP. There is a PR (https://github.com/php/php-src/pull/17895) that implements this functionality – all test failures are related to different/new/incorrect error messages being generated. However, the core functionality exists to take for a test ride.

So, what do I mean by “unprecedented amount of control”? With this change, you can declare an inner class as private or protected, preventing its usage outside of the outer class:

class User {

private class Id {}

public function __construct(public self::Id $id) {}

}

In the above example, the class User is impossible to construct even though it has a public constructor (except through reflection) because User::Id is private; User::Id cannot be instantiated, used as a type hint, or even via instanceof outside of the User class itself. This example isn’t practical but demonstrates something that is nearly impossible in previous versions of PHP, where all classes are essentially publicly accessible from anywhere within the codebase.

As a number of inner classes will probably be used as DTOs, the RFC introduces a “short syntax” for declaring classes, which enhances expressiveness, even allowing the usage of traits, all in a single line:

// declare a readonly Point, that implements Vector2 and uses the Evolvable trait

readonly class Point(public int $x, public int $y) implements Vector2 use Evolvable;

When combined with inner classes, it looks something like this:

class Pixel {

public readonly class Point(public int $x, public int $y) implements Vector2 use Evolvable;

}

// Create a new pixel point with property $x and $y set to 0

$p = new Pixel::Point(0, 0);

There are far more details in the RFC itself, so please check it out. I’m quite excited to hear your thoughts!

— Rob

PS. I know I tend to rush into things, but I want to make it clear that I’m not rushing this – I’ve learned from my mistakes (thank you to those who have given me advice). I’m going to do this right.

Hello internals,

I’ve made some major updates to the text of the RFC to clarify behaviors and revisited the implementation (which is still under development, though I hope to have a draft by the end of this weekend). Here’s a broad overview of what has changed in inner classes:

• Accessing inner classes is done via a new token: “:>” instead of “::”.

• Inner classes may now be infinitely nested.

• Inner classes may be declared abstract.

• Documented changes to ReflectionClass.

• Usage of static to refer to inner classes is restricted to prevent accidental violations of LSP.

Otherwise, there are not any big changes, but a lot of time was spent clarifying behavior and expanding on the reasoning for those decisions in the RFC itself.

— Rob

For those who are interested, I’ve opened the PR that enables this feature: https://github.com/php/php-src/pull/18069

— Rob

[Rowan_Tommins_IMSoP]

On 14/03/2025 17:37, Rob Landers wrote:

What about a hybrid approach? Maybe something like `\\` that Tim suggested?

I'm surprised nobody has pointed out yet that \ as namespace separator is already controversial because of how commonly it is used as an escape prefix, leading to a lot of situations where it has to be doubled.

A double backslash would be, literally, twice as bad, needing `\\\\` (four backslashes) to reference the name in a string, a JSON or YAML config file, a Markdown tutorial, etc

As a perfect example of this, check out how the second paragraph is rendered wrong here: RFC: short and inner classes - Externals (compare here: php.internals: Re: Re: RFC: short and inner classes)

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]

[Bilge]

Just because some (incompetent) developers cannot grasp proper escaping should have no bearing whatsoever on language design.

Cheers,
Bilge

[Rowan_Tommins_IMSoP]

On 14/03/2025 21:18, Bilge wrote:

Just because some (incompetent) developers cannot grasp proper escaping should have no bearing whatsoever on language design.

The main problem is not "grasping" it, it's the inconvenience of having to do it at all, and the "ugliness" (subjective, obviously) of the resulting code.

Backslash is used as an escape in so many different syntaxes that it's not uncommon to be nesting two of them inside each other, e.g. Markdown inside JSON:

{ "markdown": "The inner class is called MyNamespace\\\\MyClass\\\\\\\\InnerClass" }

The quadrupled namespace separator is still just about readable, but could you tell me at a glance if I have the right number of backslashes for the proposed inner class separator?

If we can't use "::", I'm confident we can find one that's more convenient to use than double-backslash.

--
Rowan Tommins
[IMSoP]

[Rowan_Tommins_IMSoP]

On 05/03/2025 23:11, Rob Landers wrote:

I'd like to introduce my RFC for discussion: PHP: rfc:short-and-inner-classes

As a user, I find the concept of inner classes quite confusing.

However, I was looking at some code earlier and thought an "inner enum" would be useful, to replace various "MODE_FOO" type class constants - but I see those are left to future scope.

I'm aware they exist in a lot of other languages, though, so I thought I'd look around at how the proposed version compares. It seems there's quite a zoo out there...

One common theme I do note is that all four of the pages I found are titled "nested classes" or "nested types"; in some cases, "inner class"/"inner type" has a specific meaning, which I don't think matches the RFC's proposal.

C# - Nested Types - C# | Microsoft Learn

I think this is most similar to what you're proposing. Interestingly, the nested class defaults to being private, i.e. only usable within the parent class.

Classes, structs and interfaces can all be nested inside each other.

Java - Nested Classes (The Java™ Tutorials > Learning the Java Language > Classes and Objects)

There are two types of nested class (plus some more related concepts which seem less relevant)

- "Static nested classes" - static in the sense that they act like a static member of the surrounding class; appear to be *only* about namespacing and visibility of the class, with no special access to the surrounding scope
- "Inner classes" - associated not just with a parent class, but a parent *instance*, so have to be created with the syntax "ParentClassName.new InnerClassName" or "this.new InnerClassName"; are not allowed to have static members

Kotlin - Nested and inner classes | Kotlin Documentation

Just nesting a class gives it no special access, but the keyword "inner" causes it to carry an *instance* of the outer class, which can be explicitly referenced with the syntax "this@OuterClassName".

Classes and interfaces can be nested in any combination.

Swift - Documentation

Type declarations of various sorts can be nested, and have all the visibility modifiers available to other declarations.

"Private access restricts the use of an entity to the enclosing declaration, and to extensions of that declaration that are in the same file" - Documentation

The example of a nested enum also demonstrates a nice shorthand syntax, where the ".ace" in "BlackjackCard(rank: .ace, suit: .spades)" is short for BlackjackCard.Rank.ace, inferred from the parameter type.

I don't have any specific conclusions, but I think with features like this it's always worth examining other people's ideas, to see if we want to include (or avoid) any of them.

--
Rowan Tommins
[IMSoP]

[Bob_Weinand]

On 15.3.2025 00:21:32, Rowan Tommins [IMSoP] wrote:

On 05/03/2025 23:11, Rob Landers wrote:

I'd like to introduce my RFC for discussion: PHP: rfc:short-and-inner-classes

As a user, I find the concept of inner classes quite confusing.

However, I was looking at some code earlier and thought an "inner enum" would be useful, to replace various "MODE_FOO" type class constants - but I see those are left to future scope.

Yeah, that's quite disappointing. I expected this to simply apply to all types of "class" until I saw the explicit exclusion.

I'm aware they exist in a lot of other languages, though, so I thought I'd look around at how the proposed version compares. It seems there's quite a zoo out there...

One common theme I do note is that all four of the pages I found are titled "nested classes" or "nested types"; in some cases, "inner class"/"inner type" has a specific meaning, which I don't think matches the RFC's proposal.

C# - Nested Types - C# | Microsoft Learn

I think this is most similar to what you're proposing. Interestingly, the nested class defaults to being private, i.e. only usable within the parent class.

The default visibility in c# is private, for everything. The RFC is consistent with the default visibility in PHP: public. c# is consistent with the default visibility for c#.

Classes, structs and interfaces can all be nested inside each other.

Java - Nested Classes (The Java™ Tutorials > Learning the Java Language > Classes and Objects)

There are two types of nested class (plus some more related concepts which seem less relevant)

- "Static nested classes" - static in the sense that they act like a static member of the surrounding class; appear to be *only* about namespacing and visibility of the class, with no special access to the surrounding scope
- "Inner classes" - associated not just with a parent class, but a parent *instance*, so have to be created with the syntax "ParentClassName.new InnerClassName" or "this.new InnerClassName"; are not allowed to have static members

inner (instance) classes in Java are quite a weird beast. I don't think it fits PHP paradigm nicely.

Bob

[Rob_Landers]

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.

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