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 <[email protected]> wrote:
> 2012/7/16 Nikita Popov <[email protected]>
>
>> 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/
Thread (21 messages)