From:
Operating system: WIN
PHP version: Irrelevant
Package: Class/Object related
Bug Type: Bug
Bug description:Arrays misbehaving with __set() and __get()
Description:
------------
Mixing __set(), __get(), and protected/private/overloaded properties that
are arrays has unexpected, undocumented, and undesirable results. A couple
of bugs listed below. One bug is similar to bug 33941, but the problem
still persists and even more bugs have popped up.
Test script:
---------------
<?php
class A {
protected $test_array = array('key' => 'test');
function __get($prop) {
if (!property_exists($this, $prop)) {
$this->$prop = null; // just to create it if it didn't
exist
}
return $this->$prop;
}
function __set($prop, $val) {
$this->$prop = $val;
}
}
$a = new A();
$a->test_array[] = 'asdf';
?>
Expected result:
----------------
New key/value "0=>'asdf'" assigned to protected class property array
'$test_array'. If the property didn't yet exist and overloading is
attempted, just create the new '$test_array' property as an array as
intended. Working with arrays in this manner should work exactly like with
any other variable type.
Actual result:
--------------
Depending on how the above test script is slightly tweaked, a few bugs pop
up. The focus here is on what happens with line "$a->test_array[] =
'asdf';"
1) If $test_array did *not* previously exist, "Notice: Indirect
modification of overloaded property A::$test_array has no effect in
...test.php on line 18". This *should've* worked fine.
2) If __set() was *not* declared, "Notice: Indirect modification of
overloaded property A::$test_array has no effect in ...test.php on line
18". This *should've* resulted in fatal "cannot access protected property"
error.
3) If $test_array did *not* previously exist and __get() was *not*
declared, it will work fine. __get() *should've* never factored in here,
and $test_array *should've* updated even if already declared
private/protected.
4) If __get() was *not* declared, "PHP Fatal error: Cannot access
protected property A::$test_array". __get() *should've* never factored in
here. If the '[]' compound operator is what's causing this, then __get()
should return a copy of the array with new or existing index if provided to
be processed through __set() as expected.
5) If $test_array was public, it will work fine, bypassing __get() and
__set() as intended. No bug here.
6) If __get() was declared to return a reference to the property (ie
function &__get($prop){}), it will work fine and bypass __set(). Not a
bug, but this workaround may cause other problems if expecting to process
updates through __set() or wanting just a copy of any other property
returned by __get().
--
Edit bug report at http://bugs.php.net/bug.php?id=52441&edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=52441&r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=52441&r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=52441&r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=52441&r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=52441&r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=52441&r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=52441&r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=52441&r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=52441&r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=52441&r=support
Expected behavior:
http://bugs.php.net/fix.php?id=52441&r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=52441&r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=52441&r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=52441&r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=52441&r=php4
Daylight Savings: http://bugs.php.net/fix.php?id=52441&r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=52441&r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=52441&r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=52441&r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=52441&r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=52441&r=mysqlcfg
