On Tue, Oct 28, 2014 at 2:17 PM, Jordi Boggiano <j.boggi...@seld.be> wrote:
> On 27/10/2014 20:27, Andrea Faulds wrote:
>>
>> Tentative syntax. But this way, the visibility stays on the left. I think
>> that’s good for readability. If you omit the second specifier, then the
>> first one applies to getting and setting, as now. If you include it, the
>> first one applies to getting, the second one to setting.
>>
>> It’d also be compatible with properties, too:
>>
>> public/private $foobar {
>> get { return $this->bar * $this->foo; }
>> set($value) { $this->bar = $value / $this->foo; }
>> }
>>
>> It doesn’t prevent truly read-only properties, either:
>>
>> public $foobar {
>> get { return $this->bar * $this->foo; }
>> }
>>
>> Does this sound like a good idea? A similar idea came up in the
>> discussions 8 years ago on readonly.
>
>
> I like it, except for the fact that if you add a custom getter to a property
> suddenly it becomes readonly unless you remember to add "; set" to the end
> of the block, right?
>
> How about this instead for readonly:
>
> public $foobar {
> get { return $this->bar * $this->foo; }; readonly
> }
>
> And if the flag isn't there, set is implicitly present.
>
> That'd mean you also can keep "public readonly $foobar;" as a shorthand for
> readonly properties without custom getter.
I like this idea.
Also confirmed what I was trying to say: While we can have many RFCs
covering the properties properties and behavior, having one covering
the needs in one go will allow us to be more consistent and developer
friendly.
--
Pierre
@pierrejoye | http://www.libgd.org
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
