Re: RFC Proposal - Attributes read/write visibility

How much syntactic sugar do we really need? Why add two ways to do something? On 16 July 2012 16:24, Amaury Bouchard <amaury@amaury.net> wrote: > 2012/7/16 Nikita Popov <nikita.ppv@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. -- Andrew Faulds (AJF) http://ajf.me/