On Sun, 20 Jan 2013 14:52:36 +0100, Sherif Ramadan
<theanomaly...@gmail.com> wrote:
I think the current behavior is most appropriate one for var_dump() (and
array casts/get_object_vars()). It's the same behavior as if you had
manually defined getXXX() methods or used __get().
It's actually not the same behavior at all. __get can only work on
inaccessible properties. So I would not see NULL there in the object and
then get a value in the instance property.
OK, it's not 100% analogous. And I'm ready to concede that the differences
that do exist may be (arguably) sufficient to draw a principled
distinction, namely:
* getXXX() is clearly a method call and not a (direct) property read and
the XXX property may not even exist.
* __get() only works on inaccessible properties, so there is no possible
confusion.
I still think you put too much emphasis on the __get() argument -- even
though there is no accessible property, there may be a protected/private
property; it it isn't the case, there's still usually some backing
storage, like a private array (shown in var_dump()) and the backing value
may be different from what's returned.
In any case, assuming this feature is accepted, the current solution,
whether in isolation it's appropriate or not, must be evaluated in the
light of the alternatives. Here, I thought you were proposing calling the
getters.
If you start marking function calls, you get new problems like handling
getters that throw exceptions or have side effects ("the code behaves
differently when add a var_dump()?!").
I'm not suggesting the getters should be invoked from afar. I'm just
suggesting some additional means of informing the user of the existence
of that getter to distinguish it from the property in the output of
var_dump.
So for example, in var_dump, you can get ["property":protected] => ...
when the property has a visibility outside of the current context. It
might be
helpful to provide some similar behavior for accessors with null
initialized values, but have getters available to the caller?
We could add some sort of marker to indicate the property is an accessor.
It would not be trivial under the current implementation as
get_properties() and get_debug_info() only return a HashTable*, so some
abstraction breaking would be required.
Another possibility would be the ability to mark some properties as not
backed by any storage, like the area in your example. But this would still
be insufficient to eliminate confusion in cases like this:
class A {
private $scale;
public $value {
get { return $this->value * $this->scale; }
set;
}
function __construct($scale) { $this->scale = (double)$scale; }
}
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
