On 7/16/12 5:29 PM, "Nikita Popov" <nikita....@gmail.com> wrote:
>On Mon, Jul 16, 2012 at 5:24 PM, Amaury Bouchard <ama...@amaury.net>
>wrote:
>> 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.
>
>You can also just write public $a { get; private set; }. I see that
>the syntax is a bit more verbose, but I definitely prefer it to the
>obscure public:private notation. With the getters/setters the meaning
>is somewhat clear (public get, private set), with the colon notation
>it isn't really clear.
He probably went with that syntax to retain full flexibility.
In our case (eZ), we almost exclusively use magic getters and setters to
make properties read only. So just like Matthew and others writing api's
we would really appreciate a way to be able to defined read only
properties, without the overhead of function calls.
I think these two proposals can be synced up, what if:
public readonly $a;
Is shorthand for:
public $a { get; protected set; }
And when no function is defined, no function overhead is added.
>
>Nikita
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php
>
>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
