Hi, I remembered the same thing, and am similarly baffled. How did the RFC pass > if you can do something as simple as `public readonly stdClass $var;`? I > thought I followed the discussion on that RFC, but apparently I missed > something. I would have expected an example like above to block acceptance > of the RFC. To be clear though, I'm mostly confused about what the > convincing argument about this was, or if it was something that everyone > else viewed as an uncontroversial aspect? >
The readonly class RFC doesn't really bring anything new to the table, just complements the readonly property RFC. The latter RFC explicitly mentions that interior mutability of properties is not restricted in any way. In my opinion, this is a wise and pragmatic approach, so that use-cases like the body stream of PSR-7 remain possible. Please note that the feature is called "readonly", not "immutable". What's your take about 8.2? As I demonstrated, readonly classes are broken > because of this propagation to child classes. Does that mean we should > remove this constraint from 8.2? What about reverting the feature and > considering it again for 8.3, after fixing it? I agree with Tim, and I also think that both reverting and making any last minute fundamental change is not a good idea, especially because people don't have a clear agreement about how inheritance should work. Readonly classes is an optional feature, so anyone who wants proxies to work can simply not add the readonly flag to their classes. Of course, it's a bit more tricky for library code, but package authors should be aware of this gotcha. Having that said, I'll try my best to fix the current shortcomings for PHP 7.3. broken. see thread I may be biased, but neither I would call the whole feature "broken". It works as intended for many regular use-cases. However, as you highlighted in the thread, there are some use-cases with which the interoperability of readonly classes is suboptimal, to say the least. This is because the RFC was designed with a conservative approach (e.g. static properties and inheritance by non-readonly classes are forbidden). This way, we'll be able to iteratively improve the feature, while we minimize the risk of introducing undesirable behavior which would be difficult to get rid of later. I know that there is a thin line between "conservative" and "incomplete", but I do hope that PHP 7.3 will be the first version where readonly properties become actually useful. Does anyone else recall this? Máté, are Jordan and I just imagining > things? It may be possible that the discussion extended to this question, but neither me (author of the previous readonly properties RFC), nor Nikita had intention to restrict the usage this way due to the reasons detailed in the first paragraph. Regards, Máté
