php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Doc Bug #41387 Magic methods __set/__get broken
Submitted: 2007-05-14 08:21 UTC Modified: 2007-08-17 09:58 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:0 (0.0%)
From: peter at ibuildings dot nl Assigned:
Status: Not a bug Package: Documentation problem
PHP Version: 5.2.2 OS: Windows XP Professional
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: peter at ibuildings dot nl
New email:
PHP Version: OS:

 

 [2007-05-14 08:21 UTC] peter at ibuildings dot nl 
Description:
------------
I've created a small class that implements the magic __set, __get and __isset methods. Using PHP 5.1.6 I can assign an array to a "fake" instance variable and then add elements to it. Doing the same using PHP 5.2.1 or 5.2.2 doesn't change the contents of the array. 

I've tried returning a reference from the __get method (e.g. changes the function definition to "function &__get($key, $value) ...", but this doesn't work either (although PHP doesn't complain about it).

If this wasn't supposed to work with PHP 5.1.6 how should I then implement this to get the desired behaviour? If this isn't possible at all then that means __set/__get are far less usable then before.

Reproduce code:
---------------
class Data
{
  private $m_data = array();

  function __set($key, $value) { $this->m_data[$key] = $value; }
  function __get($key) { return $this->m_data[$key]; }
  function __isset($key) { return isset($this->m_data[$key]); }

  function dump() { var_dump($this->m_data); }
}

$obj = new Data();
$obj->a = "a";
$obj->b = array();
$obj->b[] = '1';
$obj->b[] = '2';
$obj->b[] = '3';
$obj->dump();

Expected result:
----------------
array(2) {
  ["a"]=>
  string(1) "a"
  ["b"]=>
  array(3) {
    [0]=>
    string(1) "1"
    [1]=>
    string(1) "2"
    [2]=>
    string(1) "3"
  }
}

Actual result:
--------------
array(2) {
  ["a"]=>
  string(1) "a"
  ["b"]=>
  array(0) {
  }
}

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-05-14 08:27 UTC] judas dot iscariote at gmail dot com 
turn on error reporting and you will find the cause.

PHP Notice:  Indirect modification of overloaded property Data::$b has no effect.
 [2007-05-14 08:43 UTC] peter at ibuildings dot nl 
Ok, but this did work using PHP 5.1.6 so you can call this a regression. If I understand this correctly the only way to work-around this is using some code like the following:

$b = array();
$b[] = '1';
$b[] = '2';
$b[] = '3';
$obj->b = $b; 

Or in a more realistic case where other methods assign something to the object:

$b = $obj->b;
$b[] = '3';
$obj->b = $b;

Seems not very intuitive to me.
 [2007-05-14 19:10 UTC] derick@php.net 
But it is not a bug. As I am not sure if this is mentioned in the docs, I marked it as a documentation problem.
 [2007-05-14 20:29 UTC] peter at ibuildings dot nl 
So it seems PHP has lost some of it's "magic". 

This means that if you want to add an element to an array stored in an instance variable of a certain object you always need to be sure it's a real declared instance variable and not a "magic" instance variable. Seems a big loss to me. 

Can it not be implemented in a future version that if you declare the method as "&__get" that it works like it did before PHP 5.2 and if you declare the method as "__get" you get the PHP 5.2 behavior? Then both ways are possible and because of the explicit declaration of returning a reference (or not) it's clear what the method does.

If you implement the ArrayIterator interface, do you then stumble upon the same changed behavior? So if you implement this interface and then try to add an element to a "magic" array element (e.g. $this['a'][] = 1;), you also get a notice of some sort?
 [2007-08-17 08:31 UTC] vrana@php.net 
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.

Same as bug #41641.
 [2007-08-17 09:58 UTC] peter at ibuildings dot nl 
Check the bug number and date, this one is the oldest.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Wed Mar 12 19:01:29 2025 UTC