Re: [RFC] Readonly Properties

On 28/10/2014 15:08, Andrea Faulds wrote:

On 28 Oct 2014, at 14:24, Rowan Collins <rowan.collins@gmail.com> wrote: Andrea Faulds wrote on 28/10/2014 14:08:

On 28 Oct 2014, at 07:17, Jordi Boggiano<j.boggiano@seld.be> wrote: I like it, except for the fact that if you add a custom getter to a property suddenly it becomes readonly unless you remember to add "; set" to the end of the block, right?

Well, no. If you choose to specify getters and setters, and only specify a setter, of course it is read-only. It doesn’t make sense to have a getter and no setter and yet expect a property to be writeable.

I think the problem is that the get and set annotations are serving multiple purposes - to change the visibility, to define custom accessor/mutator code, but also to declare whether certain actions are possible at all. Since the default is for the property to be readable and writable, the fact that adding "{ get; }" makes it readonly isn't immediately intuitive, although it does makes sense once you think about it.

Hmm. Perhaps we need this, then: public $foobar; // public read, private write public/private $foobar; // public read, private write public readonly $foobar; // public read, not writeable at all This then confined set/get entirely to implementation details. A read-only property would be denoted by readonly. With the last one, you can only have get, for the first two, you must have both get and set. Does that work? Seems pretty good to me.

Yup that's definitely better than having the readonly flag in the {} block as I had it. I'd however say that it should be possible to define a writable property with only a getter and then the setter would implicitly be created. Since readonly is the way to define writability why should I have to specify a setter (even a default empty one) if none is needed? P.S: Don't want to open pandora's box, but we could also have writeonly for completeness perhaps. I don't really see the use case at all though (immutability sure, mutant bottomless pit objects not so much:). Cheers -- Jordi Boggiano @seldaek - http://nelm.io/jordi