ID:               39449
 Comment by:       mail at peter-thomassen dot de
 Reported By:      pstradomski at gmail dot com
 Status:           Assigned
 Bug Type:         Scripting Engine problem
 Operating System: Linux
 PHP Version:      5.2.0
 Assigned To:      dmitry
 New Comment:

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!


Previous Comments:
------------------------------------------------------------------------

[2006-12-06 11:08:10] brjann at gmail dot com

"// 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

------------------------------------------------------------------------

[2006-12-04 08:55:15] denis at edistar dot com

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

------------------------------------------------------------------------

[2006-11-19 11:53:11] v dot anagnostos at mail dot bg

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

------------------------------------------------------------------------

[2006-11-14 20:31:16] cboden at gmail dot com

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"

------------------------------------------------------------------------

[2006-11-09 14:05:23] pstradomski at gmail dot com

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.

------------------------------------------------------------------------

The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
    http://bugs.php.net/39449

-- 
Edit this bug report at http://bugs.php.net/?id=39449&edit=1

Reply via email to