> > Yeah, I'm definitely thinking in relation to the earlier discussion, since > I think they're all inter-related. (This, property accessors, and constant > expressions.) >
The biggest question is whether it's worth to support both readonly properties and property accessors. My answer is clear yes, because there are many-many ways to mess with private or protected properties without and public setters from the outside - in which case property accessors couldn't help much. I collected some examples I know of: https://3v4l.org/Ta4PM Please note that the first two examples also apply to private properties, while the last one only applies to protected ones. > As Nikita notes above, a read-only property with a default value is... > basically a constant already. So that's not really useful. > I agree that they are not very useful, however I wouldn't restrict their usage. Mainly because there are probably some legitimate use-cases, but I also think it would be advantageous to be consistent with the other languages in this case. > For defined-later readonly properties, I'm not sure how the earlier point > about reading an unintialized property isn't valid. Currently: > > class Foo { > public string $bar; > } > > $f = new Foo(); > print $f->bar; // this throws a TypeError. > > I would expect the exact same behavior if $bar were marked > readonly/locked/whatever. Are you saying that's not the case? > Sorry if I didn't exactly get the question/example, but what I can tell you is that currently an Error exception is thrown with the "Typed property Foo::$bar must not be accessed before initialization" message, and it would be the case with my patch as well since it doesn't affect the reading side. The situation is the same when it comes to unsetting uninitialized typed properties. Currently, these properties can be unset with no problem (and the __get(), __set() etc. magic methods are then invoked when accessing them), and the same would happen with my patch. > If we could address the performance impact, that would give us much more > functionality-for-the-buck, including an equivalent of read-only properties > including potentially lazy initialization. Or derive-on-demand behavior > would also be a big increase in functionality. > > It's not that I don't see a value to this RFC; I actually have a few > places in my own code where I could use it. It's that I see it as being of > fairly narrow use, so I'm trying to figure out how to increase it so that > the net-win is worth it. > The reason why I brought up this RFC is that I'd really like to add first-class support for immutable objects, and it seemed to be a good idea to first go for readonly properties. This way, the scope of an immutable object RFC gets smaller, while it's possible to only have readonly properties alone. Regards, Máté
