On Sun, Jan 20, 2013 at 8:08 AM, Nikita Popov <nikita....@gmail.com> wrote:
> On Sun, Jan 20, 2013 at 5:46 AM, Sherif Ramadan
> <theanomaly...@gmail.com>wrote:
>
>> I'm not sure if this has already come up in past discussion or not. So
>> I apologize in advance if this is repetitive. The discussion for property
>> accessors has been so lengthy I couldn't find the time to keep up with it
>> all.
>>
>> However, I found some time to play around with the patch today and I
>> noticed something that might use improving. When you use var_dump() on the
>> object properties that have defined get accessors don't produce any useful
>> output with var_dump. Is this fixable?
>>
>
> The var_dump will output the state of the object, i.e. the values that are
> internally stored. It will not go through the get accessors, rather it will
> directly give you the value of the underlying property. If the underlying
> property is not used, then it will just give you NULL.
>
While I agree with your initial assessment of the accessor not having set
any value, and therefore the logic of var_dump only providing what is
stored in the object's instance properties, I disagree with your
interpretation of what var_dump should do here.
Here is my reasoning for this:
1) var_dump is documented to provide you with information about a variable
(there is no mention of its implementation being limited to what the
variable stores).
2) Even if you interpret this to mean that var_dump will output the state
of the object then you are still wrong, since var_dump($foo->accessor) will
give me a value that the object does not store if the accessor returns a
computation rather than a stored value.
3) If this were a discussion of distinguishing between magic methods such
as __get/__set then we can simply say that only inaccessible properties can
invoke such methods and as such we have no confusion between what the
object stores and what var_dump returns when invoking those methods. With
accessors it is not the case at all.
Here's an example
class surface {
public $area {
get { return $this->width * $this->height; }
private set;
}
public $width {
set($val) { $this->width = $val; }
private get;
}
public $height {
set ($val) { $this->height = $val; }
private get;
}
}
$surface = new surface;
var_dump($surface);
this gives us the following output for $surface...
object(surface)#1 (3) {
["area"]=>
NULL
["width"]=>
NULL
["height"]=>
NULL
}
This is to be completely expected since, technically, all we did here was
use class initialization that provided public properties initialized to
null.
However, let's say we set $surface->width and $surface->height...
$surface->width = 4;
$surface->height = 2;
var_dump($surface);
Now $surface shows us the following from var_dump....
object(surface)#1 (3) {
["area"]=>
NULL
["width"]=>
int(4)
["height"]=>
int(2)
}
This is not accurate since var_dump($surface->area) will give us the
following...
int(8)
It's not obvious what's happening here if I'm debugging this code in real
life, because on one hand I can see that my instance property returns a
value (which I expect). On the other hand I see my object has a null
property, which I don't expect. If this were magic the property would
simply not exist and i would know to look for __get / __set magic. Now, if
we argue that accessors are magic then why do they also not work like
magic? This is a bit of a hybrid approach, and I understand the reasoning
for most of what's going on here. I'm not here to argue about
implementation details.
What I'm saying is this kind of behavior needs far more serious reasoning
than the very naive assesment you're making above.
I mean that with all due respect. Just wondering if there is another take
on this from anyone else?
Sherif,
He who asks too many questions
>
> Nikita
>
>
