On 7/23/12 12:38 PM, "Amaury Bouchard" <ama...@amaury.net<mailto:ama...@amaury.net>> wrote:
2012/7/23 André Rømcke <andre.rom...@ez.no<mailto:andre.rom...@ez.no>> 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). read-only is already mentioned here: https://wiki.php.net/rfc/propertygetsetsyntax-as-implemented#read-only_and_write-only_properties But I see now that it is defined as full read only, not even the class itself can write to it, so ignore my code examples. My point was just; we also have the need for public:protected / public:private and would like to avoid the overhead of function calls, hence why I looked into if there would be ways to sync the two proposals to improve possibility of acceptance (ref feedback in thread). 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).