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
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
