Re: RFC Proposal - Attributes read/write visibility
2012/7/23 André Rømcke <[email protected]>
> 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.
>
Well, this code:
public read-only $a;
introduces a new keyword (that should be avoided when not absolutely
necessary).
It's pretty easy to understand what it does (it's an attribute with public
access, but it's not writable), but you loose meanings (visibility).
Hence, writing
public $a { get; protected set; }
is more accurate. You recover the lost meaning. But the writing is not
straightforward.
More, should you write
public read-only $a;
or
public $a { get; private set; }
?
Beside, it seems possible to write
public read-only $a { protected get; private set; }
but that doesn't means anything.
Another examples:
public read-only $a;
vs
public:const $a;
public $a { get; private set; }
vs
public:private $a;
public $a { get; protected set; }
vs
public:protected $a;
We must be able to choose the attribute's visibility.
We should be able to read it without having to read some unnecessary code.
The PHP language should be consistent. I think the visibility information
shouldn't be distributed on several locations (before the attribute;
sometimes with a new "read-only" or "write-only" keyword; sometimes inside
brackets, before a new "get" or "set" keyword).
Thread (21 messages)