Re: Accessors v2.2 Patch
| From: | Will Fitch | Date: | Mon, 12 Dec 2011 11:22:09 +0000 |
| Subject: | Re: Accessors v2.2 Patch | ||
| References: | 1 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-56882@lists.php.net to get a copy of this message | ||
Clint,
How about
final public $Hours {}
That would allow for the read only and limit the inheritance.
Sent from my iPhone
On Dec 11, 2011, at 11:02 PM, Clint M Priest <cpriest@zerocue.com> wrote:
>
> https://bugs.php.net/patch-display.php?bug=49526&patch=v2.2&revision=1323662103
>
> This one addresses the read-only, write-only aspects. Though they are not quite what the RFC
> specifies...
>
> class TimePeriod {
> public $Hours {
> get { return 5; }
> }
> }
>
> $o = new TimePeriod();
> $o->Hours = 4;
>
> Results in:
> Fatal error: Cannot set read-only property TimePeriod::$Hours, no setter defined. in %s on line
> %d
>
> Likewise in the other direction for write-only properties.
>
> The difficulty is that one could extend TimePeriod and define a setter. This is what the RFC
> talks about when using a readonly keyword. There presently isn't a readonly keyword defined,
> nor a writeonly.
>
> Should we create a readonly/writeonly keyword, or would something along these lines be
> better/more flexible?
>
> class TimePeriod {
> public $Hours {
> get { return 5; }
> private final set { }
> }
> }
>
> Creating (forcing the author to create) a private final setter which would not allow a set to
> occur and could not be over-ridden?
>
> I've also added two tests for the read-only and write-only, as it exists in the above
> patch.
>
> Pierre, with the new/updated RFC, should I gut the sections that I decided against (such as the
> several alternate syntaxes) or leave them in?
>
> -Clint
>
>