On 28/10/2014 15:08, Andrea Faulds wrote:
On 28 Oct 2014, at 14:24, Rowan Collins <rowan.coll...@gmail.com> wrote:
Andrea Faulds wrote on 28/10/2014 14:08:
On 28 Oct 2014, at 07:17, Jordi Boggiano<j.boggi...@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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
