2012/7/16 Nikita Popov <nikita....@gmail.com>

> I'm not sure I really understand what this adds over the existing
> getter/setter proposal. read-only and write-only should cover the most
> common cases. If you do need visibility control, it is possible too:
>
> public $property {
>     get { ... }
>     protected set { ... }
> }
>
> So what does this proposal add to it?
>
>
Yes, but only if you have to write an accessor.
If you just want an attribute that is:
- readable from everywhere
- writable from the current class only

With my syntax:
    public:private $a;  (read it aloud "public reading, private writing")

With the existing RFC:
    public $a {
        private set { $this->a = $value; }
    }

Which one is better? Why should I write code for that?

If you read the existing RFC, you'll see that all examples involve a
specific case: when you have a "fake" attribute, which manipulates date
stored in other attributes. The given example is an $Hours attributes,
which is calculated from the private $Seconds attribute.
Again, it could be very useful. But it doesn't work all the time.

Reply via email to