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
Clint,
How about
final public $Hours {}
That would allow for the read only and limit the inheritance.
Sent from my iPhone
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 %dLikewise 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
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
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 %dLikewise 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