On 1/17/2013 4:24 PM, Steve Clay wrote:
https://wiki.php.net/rfc/propertygetsetsyntax-v1.2#voting
I'll say my peace on this. This is a very good implementation, and as long as authors use accessors that depend on a separate property for storage (like other langs require), everything will be straightforward. Otherwise, I fear they're in for some confusing behavior.
Consider the code from the RFC:
class TimePeriod {
public $Hours {
get { return $this->Hours ?: "not specified"; }
set { $this->Hours = $value; }
}
}
$tp = new TimePeriod();
$tp->Hours; // "not specified"
isset($tp->Hours); // true!?
$tp->Hours isset, the property exists and it's value is non-null.
The auto implementation of isset compares $this->Hours to NULL, but since $this->Hours goes through the getter, it will return "not specified". So the property will always appear to be isset.
* The guards seem spooky: A set of tokens ($this->prop) will have varying behavior (e.g. direct prop read vs. getter call) *depending on the call stack*.
This is the same as would occur with isset against an undefined property, that would call __isset(), followed by __get() which would then compare the value to NULL.
* Giving issetter/unsetter no direct access to the property limits functionality and leads to weirdness like the example above.
This is possible, simply by supplying your own implementation of isset/unset that calls isset/unset, such as:
public $foo {
get; set;
isset { return isset($this->foo); }
unset { unset($this->foo); }
}
The above five lines of code is exactly equivalent in functionality to:
public $foo;
-Clint