Search code examples
phpgetter-settermagic-methodspre-increment

Pre-increment in PHP with magic get and set defined

I have a problem that has been spoiling the way I want to do the things for a long time. It's related to the use of magic get and set in PHP and trying to do a pre-increment over an object. I have a PHP class like the following:

class Foo {
    public $object;

    function __construct() {
            $this->object = array("bar" => 1);
    }

    function & __get($name) {
            return $this->object[$name];
    }

    function __set($name, $value) {
            echo "Old value: ". $this->object[$name] ." - New value: ". $value ."\n";
            $this->object[$name] = $value;
    }
}

Note the & in the __get method. Now I run this code:

$o = new Foo();

echo "First test\n";
$o->bar = 2;

echo "Second test\n";
$o->bar = $o->bar + 1;

echo "Third test\n";
$o->bar += 1;

echo "Fourth test\n";
++$o->bar;

And the output is:

First test
Old value: 1 - New value: 2
Second test
Old value: 2 - New value: 3
Third test
Old value: 4 - New value: 4
Fourth test
Old value: 5 - New value: 5

The third and fourth tests have an unexpected (by me) behaviour. Looks like $this->object['bar'] returns the value to be set, instead the old value as I expected. How come the value is already set even before it's actually set?

If I remove the & from the __get method, this will work, so I guess it has something to do with the references management that PHP does. But I would expect the third test to behave the same way as the second, but it doesn't.

I really don't understand this. Any help would be much appreciated.

Solution

  • The results are in fact (after careful consideration) what I would expect.

    First test

    Code: $o->bar = 2;
    Output: Old value: 1 - New value: 2

    The operations, in order:

    • Assign a new value to $bar (call __set())

    Obviously this simply abandons the old value and puts a new value in its place. Nothing complicated.

    Second test

    Code: $o->bar = $o->bar + 1;
    Output: Old value: 2 - New value: 3

    The operations, in order:

    • Get a copy of $bar (call __get())
    • Add one to it
    • Assign a new value to $bar (call __set())

    The right side of the expression is evaluated, and the result is assigned to the left side. The value of the instance variable $bar is untouched during the evaluation of the right side, so you see it's old value at the beginning of the __set() call.

    Third test

    Code: $o->bar += 1;
    Output: Old value: 4 - New value: 4

    The operations, in order:

    • Get a reference to $bar (call __get())
    • Add one to it
    • Assign a new value to $bar (call __set())

    This is interesting - at first glance I'm a little surprised that you see the output generated by __set() with this operation. Because you are incrementing the value held in the original zval, not assigning a whole new value - and therefore a whole new zval - as you were with the first two, it seems that the __set() call is redundant.

    However, when __set() is called the output that you do see is what you would expect, because the referenced value has been incremented before __set() was called. The value passed to __set() is the result of the increment operation, so it does not result in another one being added to it, it simply assigns the value of $foo->bar to $foo->bar - so you see the old and new values as being the same.

    Fourth test

    Code: ++$o->bar;
    Output: Old value: 5 - New value: 5

    ...semantically identical to the third test. The exact same operations in the exact same order resulting in the exact same output. Again, a little odd that there is any output at all, but there you go.

    Fifth test that I invented

    Code: $o->bar++;
    Output: Old value: 5 - New value: 6

    ...semantically identical to the second test. This is again interesting and slightly unexpected, but it also makes sense, given that $i++ returns the old value of $i.

    At a guess the reason that __set() is being called unnecessarily in the third and fourth tests is:

    • (unlikely but possible) because it would be more computationally expensive to work out whether __get() returned a reference or a copy than it is to simply call __set() - this seems unlikely since function calls are generally quite expensive.
    • (more likely) because the __set() function can contain code that is nothing to do with the actual assignment operation, and it would be potentially seriously inconvenient if this code did not run when the value was altered. For example, if one was to implement some kind of event driven architecture that fired events when certain values were altered, it would be annoying if that only worked with straight assignments.