Bug #70044 [Com]: Magic __set(), first parameter "undefined" when passed an array "part"

From: Date: Mon, 13 Jul 2015 05:02:38 +0000
Subject: Bug #70044 [Com]: Magic __set(), first parameter "undefined" when passed an array "part"
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-194371@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=70044&edit=1 ID: 70044 Comment by: landers dot robert at gmail dot com Reported by: landers dot robert at gmail dot com Summary: Magic __set(), first parameter "undefined" when passed an array "part" Status: Not a bug Type: Bug Package: Class/Object related Operating System: Docker/Ubuntu PHP Version: 7.0.0beta1 Block user comment: N Private report: N New Comment: :doh: Thanks for that... Previous Comments: ------------------------------------------------------------------------ [2015-07-12 02:34:45] requinix@php.net *if you had returned $this->vars[$var] ------------------------------------------------------------------------ [2015-07-12 02:33:30] requinix@php.net http://3v4l.org/5SH8M (3v4l may be having issues though) Running that code you'll get an array-to-string notice (putting $value in a string), a "set" message, a "got" message, and another notice. The "set" and "got" messages are obviously supposed to be there, but there will not be a second "set" because you are not trying to set a property of the object. To do so you must actually have a "$base->base_class = ...". Modifying a return value will not trigger it. The second notice speaks to that point: >Notice: Indirect modification of overloaded property baseClass::$base_class has >no effect in %s on line %d What __get returned was (null because you didn't put a return in there, but if you had returned $this->vars[$value] then it would be) a copy of the "test" array. PHP noticed that you tried to modify this copy and specifically warned you that it would not work. Make __get() return by-reference so that you modify the "original" array and not a copy. Note this only works for values that can be referenced, like $this->vars[$var], and not for expressions or literal values. Which will not trigger a second __set() either. ------------------------------------------------------------------------ [2015-07-12 02:23:31] landers dot robert at gmail dot com After some further investigation, it looks like the "var name" parameter is not set or unset when called like this. I updated the title to reflect this. ------------------------------------------------------------------------ [2015-07-12 02:16:55] landers dot robert at gmail dot com Here's a derived example. Looks like __set doesn't like arrays... <?php class baseClass { var $vars = []; function __get($var) { echo "got $var<br>"; var_dump($this->vars[$var]); } function __set($var, $value) { echo "set $var = $value<br>"; $this->vars[$var] = $value; echo "<pre>"; var_dump($this->vars[$var]); echo "</pre><br>"; } } $base = new baseClass(); $base->base_class = []; $base->base_class['test'] = "hi"; // this doesn't work! ?> But $var should be set to "something", it doesn't look like it is set to anything useful. ------------------------------------------------------------------------ [2015-07-11 07:32:16] requinix@php.net Thank you for this bug report. To properly diagnose the problem, we need a short but complete example script to be able to reproduce this bug ourselves. A proper reproducing script starts with <?php and ends with ?>, is max. 10-20 lines long and does not require any external resources such as databases, etc. If the script requires a database to demonstrate the issue, please make sure it creates all necessary tables, stored procedures etc. Please avoid embedding huge scripts into the report. ------------------------------------------------------------------------ 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 https://bugs.php.net/bug.php?id=70044 -- Edit this bug report at https://bugs.php.net/bug.php?id=70044&edit=1

« previous php.bugs (#194371) next »