> On 24 Oct 2014, at 11:20, Nikita Popov <nikita....@gmail.com> wrote:
>
> While I think the functionality behind this proposal is nice in principle, I
> have two objections with the RFC:
>
> 1. It uses the "readonly" modifier, to refer to a property that is publicly
> readable, but protectedly writable (or protectedly readable and privately
> writable). This isn't entirely obvious from the term "readonly" and also does
> not match the behavior of other languages employing a "readonly" modifier,
> like C#. An additional complication may be encountered in the case where the
> readonly property stores an object, in which case I presume it will be
> possible to modify the stored object ($obj->readonlyProp->prop = 42), which
> is likely not expected "readonly" behavior.
It’s not the best name, I agree, but there isn’t a better name I could come up
with in discussions. I don’t think the object thing is an issue, it’s not like
there’s much we can do about that.
>
> 2. If the aim of this RFC is to replace the getFoo() pattern with the use of
> "readonly public $foo" properties, a primary difference will be that a
> getFoo() method can be declared in an interface, whereas a "readonly public
> $foo" property cannot be. Thus code making use of interfaces will not be able
> to employ this feature. And I don't think that allowing properties in
> interfaces is reasonable at this point, because the implementations will be
> limited to simple-storage properties - only with more comprehensive property
> accessor support would implementations be allowed to use more complex backing
> code.
Right, interfaces currently can’t declare properties and I’m not going to
change that in this RFC. If I revisit getters and setters, that would be
changed. Still, I think there is usefulness to this without interfaces… it’s
just more limited, sadly.
It would work quite well with getters and setters and interfaces, if later
added. Within interfaces, readonly could be used to avoid compelling
implementing classes to support writing:
interface Point {
public readonly $x, $y;
}
But without preventing implementing classes from supporting it.
--
Andrea Faulds
http://ajf.me/
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
