Description:
------------
It is now impossible to implement overloaded array properties. Array
returned via __get is now a copy (not a reference as in 5.1.x) and it is
impossible to force getter to pass a reference.

Reproduce code:
---------------
<?php

class A {
public function & __get($val) {
  return $this->keys[$val];
}
public function __set($k, $v) {
  $this->keys[$k] = $v;
}
private $keys = array();
}

$a =new A();

$a->arr = array('a','b','c');

$b = &$a->arr;
$b[]= 'd';

foreach ($a->arr as $k => $v) {
  echo "$k => $v\n";
}

$a->arr[]='d';

foreach ($a->arr as $k => $v) {
  echo "$k => $v\n";
}

?>

Expected result:
----------------
0 => a
1 => b
2 => c
3 => d

0 => a
1 => b
2 => c
3 => d
4 => d

Actual result:
--------------
Notice: Indirect modification of overloaded property A::$arr has no
effect in /home/pawel/tmp/a.php on line 18

Notice: Indirect modification of overloaded property A::$arr has no
effect in /home/pawel/tmp/a.php on line 21
0 => a
1 => b
2 => c

Notice: Indirect modification of overloaded property A::$arr has no
effect in /home/pawel/tmp/a.php on line 25

Notice: Indirect modification of overloaded property A::$arr has no
effect in /home/pawel/tmp/a.php on line 27
0 => a
1 => b
2 => c

This is expected behaviour.

Reopening.

This should never be "expected behaviour". This way encapsulation got
severly broken - __get was introduced to allow dynamic creation of
properties - and therefore implementation of record-like classes. Such
properties were meant to be indistinguishable from standard properties -
but aren't. Neither passing by reference works, nor array elements do.

Developer can expect to be able to modify object properties for example
in such a way:

$x->arr = array('a');
array_push($x->arr, 'b');

Now it is impossible - although it should be. I understand previous
behaviour could be considered improper, bu now developers don't even get
a chance to choose between passing by value and passing by reference.

In the above example:
  $a->arr[]='d';
produced the expected results in PHP-5.1 but now gives the following
error in PHP-5.2
"Notice: Indirect modification of overloaded property"

Reproduce code:
---------------

<?php

class A{
	
	private $test = array(1,2,3,4,5);
		
	public function __get($v){
		return $this->test;
	}

}

$a = new A;

foreach( $a->overloaded_property as $val )
	echo $val."<br />\n";

?>

Expected result:
----------------

1
2
3
4
5

Actual result:
--------------

Notice: Indirect modification of overloaded property
A::$overloaded_property has no effect in
C:\Apache\htdocs\dancho\index.php on line 15
1
2
3
4
5

I think the warning should be raised only when someone is 
trying to write the overloaded property.

Foreach and other loop constructs are readonly constructs 
except when they are using references of the overloaded 
properties.

For example:
<?php

class A{
        
        private $test = array(1,2,3,4,5);
                
        public function __get($v){
                return $this->test;
        }

}

$a = new A;

// This should not raise notice
foreach( $a->overloaded_property as $val )
        echo $val."<br />\n";

// This should raise notice
$a->overloaded_property[] = 6;

?>

Thank you,
Denis

"// This should not raise notice
foreach( $a->overloaded_property as $val )
        echo $val."<br />\n";

// This should raise notice
$a->overloaded_property[] = 6;"

I do not agree with that. Neither of the examples should raise a notice.
There is no reason for

$a->overloadedprop = $bar

to work, but not

$a->overloadedprop[$foo] = $bar 

or

foreach($a->overloadedprop){}

Either properties can be overloaded and therefore read, assigned and
iterated over, or not. Overloaded properties should behave the same way
as ordinary properties, or else the object's behaviour is
unpredictable.

Perhaps the solution of using __get() to return a reference is
unsatisfactory in some way, but the behaviour should still be there.

/Brjánn

I do agree with Denis in the sense that one should disable 
the notice for read access (using foreach, p.ex.), until a 
global solution including write access is found (or not). 
This doesn't harm anyone and would save me some lines of 
error_reporting() changes. Thanks!

I agree strongly with brjann's analysis.  Once the language allows
overloaded properties on an object, it's completely confusing to say
that overloaded array properties are immutable while all other property
types are mutable, and also that non-overloaded array properties can be
iterated with foreach but overloaded array properties cannot be
iterated.

I've got a significant amount of code that will have to be rewritten
because of this change.  The symfony framework encourages a design
pattern that uses overloaded properties on the action objects and any
instances where the overloaded property is an array are now broken. 

Other symfony users have run into the problem as well
(http://www.symfony-project.com/forum/index.php/m/15684/#msg_15684).

David Morandi

Just adding a comment to say this "feature" is also going to cause me a
lot of pain changing code.

Any reason it is "expected behaviour" or do we just get a 4 word reply
basically saying **** you ?

I do agree with the brjann points and also vote for this 
behavior to be fixed; there's no way for me to knowing if any 
particular property is overloaded or not, neither it is right 
to treat them differently from any other properties.

Fixed in CVS HEAD and PHP_5_2.

I am still seeing this issue on PHP 5.2.5.

Here is a link to a PEAR class affected:
http://pear.php.net/bugs/bug.php?id=10702

The method in question can be found here:
http://pear.php.net/package/XML_Feed_Parser/docs/latest/__filesource/f
source_XML_Feed_Parser__XML_Feed_Parser-1.0.2ParserType.php.html#a189

Changing 

$this->idMappings[$id] = $this->entries[$offset];

to

$mappings = $this->idMappings;
$mappings[$id] = $this->entries[$offset];
$this->idMappings = $mappings;

fixes the notice ..

For me it's hard to understand, what it should be, that you call fixed.
I searched quite a while, but I came to the conclusion, that fixing was
just closing the thread?
If it stays as it is, the overloading in case of __get and __set is
completely useless, because noone limits himself to simple variables or
uses such sick constructs. Is it really the solution to read the whole
array, modify it the way you need and write it back as lsmith posted?
Come on...

The original test-cases from first post and from [19 Nov 2006 11:53am
UTC] work fine for me. The following code is not covered by this.

$this->idMappings[$id] = $this->entries[$offset];

The warning message is expected here.

You can fix it by redefining __get() with return by reference.

No feedback was provided for this bug for over a week, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Not fixed in PHP 5.2.4.
Is there any plan to fix this bug?

I entirely agree with brjann that "normal" and overloaded properties
should behave the same. Overloaded array properties should be possible.

Still not fixed in 5.2.5

Works correctly for me on 5.2.6. Did you forget to add the & before
__get definition?

It's fixed. Please RTFM next time. (if this is not covered by the
manual, open a new bug report with 'Documentation problem' as the
category.