RFC: short and inner classes View as Markdown

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

I think the RFC was a bit unclear on this. Short classes can have
methods. The short syntax just doesn't provide the ability to define
them whilst defining the class.

But otherwise they are indistinguishable from normal classes and they
can have methods by inheriting them or by using traits.

BR,
Juris

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.

I put a lot of thought into this issue off and on, all day. I've decided to remove short syntax from the RFC and focus on inner classes. If this passes, then I will propose it as a separate RFC. Introducing them concurrently makes little sense in light of the feedback I have gotten so far, and it is turning out that there is much more to discuss than I initially expected.

Thus, I will skip replying about short classes.

As for the “Inner classes” proposal:

• “abstract is not allowed as an inner class cannot be parent classes.”
• Why?

This is mostly a technical reason, as I was unable to determine a grammar rule that didn't result in ambiguity. Another reason is to ensure encapsulation and prevent usages outside their intended scope. We can always add it later.

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

Thank you for pointing this out! I learned something new today! I've updated the RFC.

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

It doesn't affect LSP. I've updated the RFC accordingly.

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

It's a slightly interesting story about how I arrived at this particular implementation. If you noticed the branch name, this is the second implementation. The first implementation used a dedicated list on the class-entry for inner classes. Since I wanted to prevent static property/consts from being declared with the same name, I had just set it to a string of the full class name as a placeholder. That implementation also required some pretty dramatic OPcache changes, which I didn't like. At one point, I went to add the first test that did new Outer::Inner() and the test passed...

You can imagine my surprise to see a test pass that I had expected to fail, and it was then that I went into the details of what was going on. Any new ClassName essentially results in the following AST:

ZEND_AST_NEW
-- ZEND_AST_ZVAL
-- "ClassName"
-- (... args)

The original grammar, at the time, was to reuse the existing static property access AST until I could properly understand OPcache/JIT. My change had resulted in (approximately) this AST:

ZEND_AST_NEW
-- ZEND_AST_ZVAL
-- ZEND_AST_STATIC_PROP
-- "Outer::Inner"
-- (... args)

Which, effectively resulted in emitting opcodes that found the prop + string value I happened to put there as a placeholder until I figured out a better solution, handling autoloading properly and everything. This pretty much negated all efforts up to that point, and I was stunned.

So, I branched off from an earlier point and eventually wrote the version you see today. It's 1000x simpler and faster than the original implementation (literally), since it uses all pre-existing (optimized)) infrastructure instead of creating entirely new infrastructure. It doesn't have to check another hashmap (which is slow) for static props vs. constants vs. inner classes.

In essence, while the diff can be improved further, it is quite simple; the core of it is less than 500 lines of code.

I'd recommend leaving any comments about the PR on the PR itself (or via private email if you'd prefer that). I'm by no means an expert on this code base, and if it is not what you'd expect, being an expert yourself, I'd love to hear any suggestions for improvements or other approaches.

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.

I literally fell out of my chair laughing. Thanks for that, and it is true. I look forward to discussing this further!

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.

Indeed! See: https://externals.io/message/126331#126337

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.

Thank you, this is fixed!

— Rob

Hi

  Closure::fromCallable('Outer::Inner::method');

You end up with:

object(Closure)#1 (1) {
["function"]=>
string(20) "Outer::Inner::method"
}

Okay, does calling the closure work and correctly call the method on
the inner class? The question was intended to make sure that the
implementation for callables uses the correct :: to split. Here's
another one that might be interesting:

 Closure::fromCallable(["Outer::Inner", "method"]);
 Closure::fromCallable(["Outer", "Inner::method"]);

  constant('Outer::Inner');

This returns:

string(12) "Outer::Inner"

Okay, so this behaves as a constant containing the class name. I assume
it's with the full namespace if the outer class is namespaced? I'm not
sure if I want this to work like this (i.e. whether this should be an
error).

  $inner = 'Inner';
  Outer::{$inner};

This does nothing (but resolves to "Outer::Inner")

It's consistent with constant() and that's good.

… 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():

I don't think the RFC explains “resolution” at all. That's why I'm
asking with those specific “edge-casey” examples, so that the RFC
explicitly spells out the behavior. This is not something that should be
“implementation defined”, but something where an explicit design
decision has been made.

I also don't understand why new C::Inner() (w|sh)ould resolve to
P::Inner(). I think my expectation of the code snippet above would be
that it is an error.

Likewise, LSP being ignored for inner classes raises an interesting
question about the behavior of:

 class P {
     class Inner {
         public function __construct(public string $foo) { }
     }

     public static function create() {
         return new static::Inner('x');
     }
 }

 class C extends P {
     class Inner {
         public function __construct(public int $bar) { }
     }
 }

What happens if I call C::create()? This should also be specified in
the RFC (and tested with a .phpt test).

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.

We should remove the number of strange things, not add to them.

Best regards
Tim Düsterhus

Hi Bob

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

Hey Ilija,

Hi Bob

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

Hi Rob

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

Hey Ilija,

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

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:

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:

I was specifically echoing this callout from Michał earlier in this thread and other emails/comments I have gotten off-list; including my own libraries. I usually have DTOs that I want to use specifically for certain things, but not expose them in the user application -- or even the rest of the library. This isn't a replacement for "modules" or "namespace privacy" but rather, complements it, if we ever implement it.

— Rob

Hey Rob,

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

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

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.

You can achieve the same with "file private" access: in your example mark the constructor as "file private", and put the Builder in the same file

fileprivate function __construct(private array $points) {}

If you'll excuse a brief philosophical detour, I noticed something interesting in the Swift documentation: the description of nested classes doesn't describe any special scope access. Instead, the description of "access levels" defines "private" in a way that naturally includes them:

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

It's a subtly different framing - nested types aren't breaking into the private entity, the "private" keyword is explicitly letting nested types in.

A language could, if it chose, have different keywords for "private to exactly this type" and "private to this type and any nested types":

strict_private function __construct(private array $points) {}
private_or_nested function __construct(private array $points) {}

Just as there are many combinations like "this class, subclasses, or other classes in this module".

The point being that there's nothing fundamental about nested types that gives them access to private properties. What they do is give us a new dimension to define access levels of our choice - { contains, contained by, neither }.

File scope gives us instead the dimension { same file, different file }; and module scope gives us { same module, different module, no module }, and maybe some additional relationships between modules.

Rowan Tommins
[IMSoP]

Le 15 mars 2025 à 12:53, Rowan Tommins [IMSoP] imsop.php@rwec.co.uk a écrit :

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

According to my archeological research, it was originally designed to reuse :: as namespace separator, but it was finally changed to something else due to ambiguity between static class elements and namespaced functions/constants. See https://wiki.php.net/rfc/namespaceissues and https://wiki.php.net/rfc/backslashnamespaces (where :: is assumed to be the namespace separator).

—Claude

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 don’t think \ is viable. If we used slash it would complicate autoloading and be impossible to differentiate between

namespace Outer;

class Inner {}

And

class Outer {
class Inner {}
}

These would both resolve to the same class name for Outer\Inner. Which one it resolves to would depend on how you implement autoloading (which may be desirable for BC reasons). Then there becomes the question of either letting user-land implement the autoloading changes, or have php walk “up” the namespace chain in the hopes it implements an inner class.

So, maybe, it could be useful to use \ but in the long run, I’m not sure it makes sense.

— Rob

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

This wording feels a bit disingenuous - clearly, you can grasp some advantages. It's fine if you don't think those advantages outweigh the disadvantages, but that's different from believing they don't exist.

In other words, it's like the famous Monty Python joke:

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.

Absolutely, but where there's a wide adoption of a particular pattern or style, it's worth at least asking whether we're making things better or worse by doing something different.

If we look at that, and decide we can do something better, great!

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

Personally, I would be equally happy with either \ or :: and less happy with anything that required us choosing yet another set of punctuation, for what is otherwise quite a minor feature in its language impact.

Rowan Tommins
[IMSoP]

Hey Rob,

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.

PHP doesn't go out of its way to prevent the developer from violating LSP -- but where it can, it does. If a type were inherited, then the subclasses wouldn't be able to guarantee that an inner/nested class implemented the parent inner/nested class. Or, if it did, it would require that all subclasses using a class of the same name MUST inherit from the parent class as well.

This is non-trivial to implement as the parent class may or may not have been compiled yet when we are compiling the subclass. So, we have no idea what the parent class actually looks like until runtime. Further, it is much simpler to reason about each class as a distinct type vs. maybe inheriting a type from a supertype.

Thus, if you want to inherit from the super-class's inner classes, you can, but this RFC won't force you to do so. In my mind, this is the biggest argument for a \, because the enclosing class acts more like a namespace than a type, from the perspective of the inner class.

If we were to embrace \, then it could be argued that a namespace is technically a class in itself, (but a partial class, to borrow from C# terminology) and every class in a namespace is essentially just a public class in that super-class/namespace.

Nobody has argued that perspective, but I believe it may be interesting (and would lay a foundation for namespace private/public class behavior/visibility). That being said, it truly does cause issues with autoloading -- at least, PSR-4 autoloading -- and I'm not sure whether we should solve that problem here; however, it is something to be cognizant of, for sure. There are other types of autoloading supported by tools, such as composer, that do not have any issues with using \ as a separator.

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

🙃sometimes the obvious solutions are the best solutions.

— Rob