|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #42030 Cannot use __set and __get with arrays (Indirect modification of overloaded...)
Submitted: 2007-07-18 12:46 UTC Modified: 2007-07-19 13:23 UTC
Avg. Score:5.0 ± 0.0
Reproduced:2 of 2 (100.0%)
Same Version:2 (100.0%)
Same OS:1 (50.0%)
From: luke at liveoakinteractive dot com Assigned: helly (profile)
Status: Not a bug Package: Class/Object related
PHP Version: 5.2.3 OS: Ubuntu 7.04 / RHEL 4
Private report: No CVE-ID: None
Welcome back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If this is not your bug, you can add a comment by following this link.
If this is your bug, but you forgot your password, you can retrieve your password here.
Bug Type:
From: luke at liveoakinteractive dot com
New email:
PHP Version: OS:


 [2007-07-18 12:46 UTC] luke at liveoakinteractive dot com
Good morning!

I've found what I'm reasonably certain is a bug, and I've searched to verify that nobody has reported the same issue. I see some similar issues reported by others, but I don't think any are identical. Hopefully I'm not beating a dead horse.

The issue I've run into is that __get and __set cause odd behavior if you're trying to get or set a piece of an array (e.g. $object->arr[1] = true;). It returns back a notice: "Indirect modification of overloaded property ClassName::$my_array has no effect" (and indeed it doesn't; the assignment or retrieval do not work!).

You can get around this by assigning the entire array in advance and then assigning the array as a unit to the object, and retrieving similarly (the entire array first, then in pieces). However, it seems to be the case that I should be able to assign pieces of arrays here just like anywhere else.

As an additional note, if the array is an actual class property, it works.

Thanks so much for your time!
Luke Sneeringer
Live Oak Interactive

Reproduce code:
class ClassName {
  private $fields;
  public $class_array;

  public function __get($key) {
    if (isset($this->fields[$key])) {
      return $this->fields[$key];
    else {
      return null;

  public function __set($key, $val) {
    $this->fields[$key] = $val;

$c = new ClassName;
$c->scalar = 'two'; // works
$c->an_array[3] = 'three'; // throws notice
$diff_array[3] = 'three';
$c->diff_array = $diff_array; // works
$c->class_array[4] = 'four'; // works

Expected result:
I would have expected an assignment such as $c->an_array[3] = 'three'; to assign as expected.

It certainly seems intuitive that one should be able to assign an array in this manner, and I saw nothing in the documentation indicating otherwise. An array as a whole can be stored this way (as the second working example indicates); there just seems to be something about assigning a particular piece that breaks.

Incidentally, retrieving suffers from the same issue...I can retrieve the array as a whole, but not a piece of it.

Actual result:
I get an error of level E_NOTICE: Indirect modification of overloaded property ClassName::$an_array has no effect. The assignment or retrieval, as the notice indicates, does not work.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2007-07-18 14:25 UTC]
Assigned to Marcus who added this notice. Please explain these people why it is there. :)
 [2007-07-18 14:27 UTC]
See also bug #41641
 [2007-07-19 13:00 UTC]
Please do not submit the same bug more than once. An existing
bug report already describes this very problem. Even if you feel
that your issue is somewhat different, the resolution is likely
to be the same. 

Thank you for your interest in PHP.

 [2007-07-19 13:23 UTC] luke at liveoakinteractive dot com
I fail to see how this is the same issue, since in the other bug posted, the code worked as expected (the assignment occurs, just the notice is bogus), and here the code does not function properly. (Also, in my defense, yesterday 41641 was listed as a "documentation problem".)

I suppose it's primarily a semantical issue, and I don't mean to split hairs by pointing it out; I just want to make sure that when 41641 is addressed, that this issue is also. :) It is certainly the case that they're related issues and likely stem from the same root problem (that __get and __set handle array assignment improperly).

Thank you kindly!
 [2012-07-09 07:45 UTC] alonso dot vidales at tras2 dot es
I think that this bug is not the same than bug #41641 , we are trying to set the 
var from out of the object scope.
Did you do something to fix this?, I'm able to reproduce it using the next code:

class test
    private $params = array();

    function __set($name, $value)
        echo "SETTING: " . $name . " - " . $value . PHP_EOL;
        $this->params[$name] = $value;

    function __get($name)
        echo "GETTING " . $name . PHP_EOL;
        return $this->params[$name];

$test = new test();
$test->prop1 = array('jose' => 'bbb');
$test->prop1['jose'] = 123;

echo $test->prop1['jose'] . PHP_EOL;

Expected result:
The last echo should to show "123" instead of 'bbb' because the value was 
modified, but it show 'bbb'

Tested with PHP version: 5.3.10
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sun May 26 06:01:31 2024 UTC