RE: [PHP-DEV] Accessors v2.2 Patch

This wouldn't quite address the concern. This already works and prevents any modification/override to the accessor. The spec talks about being able to allow an over-ride of the get and non-override of the setter (or in the readonly case, no setter defined). -----Original Message----- From: Will Fitch [mailto:will.fitch@gmail.com] Sent: Monday, December 12, 2011 5:22 AM To: Clint M Priest Cc: internals@lists.php.net Subject: Re: [PHP-DEV] Accessors v2.2 Patch 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 > >