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?

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