[PHP 8.2] Add readonly class support

[TomasVotruba]

Ref https://wiki.php.net/rfc/readonly_classes

PHP src: php/php-src#7305

[TomasVotruba]

Ready for review 👍

[nikic]

This is missing a pretty printer test (and maybe pretty printer implementation -- not sure if this works out of the box).

[TomasVotruba]

This is missing a pretty printer test (and maybe pretty printer implementation -- not sure if this works out of the box).

I've added simple print. Seems working as the modifier method is universal.

[TomasVotruba]

Ready for review ✔️

[TomasVotruba]

I've added the custom check for class modifiers.

Let me know if that's ok. Otherwise good to review ✔️

[nikic]

Can you please regenerate the Php7.php file to fix the merge conflict?

[TomasVotruba]

Can you please regenerate the Php7.php file to fix the merge conflict?

Done 👍

[kocsismate]

@TomasVotruba Thanks for the implementation! I've just noticed a slight difference between how properties of a readonly class is handled by php-src and PHP-Parser: while the former automatically assigns the readonly flag to any such property,
PHP-Parser doesn't do so. The behavior of php-src is highlighted at php/php-src#7305 (review)

Can we allow this inconsistency or should this be changed on PHP-Parser's part?

[TomasVotruba]

Thank you, that's an interesting question.

So any property inside the readonly class should have implicit readonly modifier? How would you differ between implicit readonly modifier, when it comes to printer?

I think we have same convention for final classes. Their properties and methods are nor marked as final, even if PHP sees them this way.

Saying that, I think php-parser is different from php-src, as the former parsers what it sees (and nothing implicit) and later covers implicit behavior not to allow invalid run. Like wysiwyg vs. runtime.

Maybe different point of views: What real php-parser use case is negatively affected by this?

[kocsismate]

Saying that, I think php-parser is different from php-src, as the former parsers what it sees (and nothing implicit) and later covers implicit behavior not to allow invalid run. Like wysiwyg vs. runtime.

Aha, it sounds like a good rule of thumb, and makes sense to me.

Maybe different point of views: What real php-parser use case is negatively affected by this?

Hmm, I'm not aware of any. Although, I'll have to adapt the readonly class support in my PR :)

P.S. @nikic Can you please make a PHP-Parser release so that I can update it in php-src?