Hi Rob, czw., 6 mar 2025 o 00:16 Rob Landers <rob@bottled.codes> napisał(a):
> 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. > Inner classes - YES, Short classes - YES, Short empty classes - YES - very nice solution for extending Exception class, maybe there is no need for parentheses??, Traits in single line - dunno, personally don't see the need so no much preference here, IMO would be debatable. Especially both together. Inner classes are something I was thinking about many years ago [1]. And the short classes are something that is also in my field of interest. I remember this was proposed some time ago on ML. Currently, all of the classes replace array-shapes I mark with additional docblock including `@internal` tag. Many DTO's have no logic or not that much, meaning they don't need methods. An example which you may think could be expressed differently but since I'm used to expressing my opinion as fast as possible this is what came to my mind now. Possibly not all of the inner classes should be inner, but there is one that definitely should be, see: final class TZParser { /** * @param TZTypeInfo[] $types * @param TTInfo[] $transitions * @param string[] $abbreviations * @param array<int,array{timestamp:int,corr:int}> $leapSecondData */ public class TZInfo( string $version, bool $isV2Plus, array $types, array $transitions, array $abbreviations, array $leapSecondData, string|null $posixString, ); protected class TZTypeInfo(public int $gmtOffset, bool $isDst, int $abbreviationIndex, bool $isStd = false, bool $isUt = false) protected class TTInfo(int $timestamp, int $typeIndex); private class TZInfoSection(array $types, array $transitions, array $abbreviations, array $leaps, int $newOffset); public static function parse(string $filename): TZInfo { /** impl */ } } While it looks different with short class and doc block for TZInfo, for the others that don't require docblock this is pretty nice, even if the fields would be declared each in a separate line - it's a personal preference. Additionally, I could easily remove the some prefixes I see this way of declaring DTO's more convenient than having 3 separate files for just a small DTO class where I need to put `/** @internal */` on each of them. Inner classes won't be possible to instantiate outside of the TZParser class which is intended here. All instances should be available outside of the parser to read the information with one exception for TZInfoSection. In this example the TZInfoSection class is used internally (which is why marked as private) by the parser itself, it's not exposed outside because there is no real use case for that which makes this feature very interesting to me. If the RFC would be splitted into smaller or not I say YES for inner+short(and empty). I hope others will see proposed features as useful as I. Good luck. [1] https://brzuchal.com/posts/inner-classes-in-php-concept/
