Unknown W. Brackets wrote:
The __set() method is called when a property of a class is set, __get() when a property is retrieved.
An array is simple a way of listing things; the array itself is a piece of data. When you set a key in that array, you are not setting the
I know these things.
array. It may help to think of it like this:
it's doesn't because object != array. as long as you stick to nesting objects
in this way everything is fine because __set() is called on the object
returned by __get() at the previous level - meaning control is maintained
by the object.
basically if I have an overloaded property that is an array I can bork it's
contents completely from outside of the object and the object doesn't get
anything to say about it.
medical analogy to observed behaviour:
if your liver was an array, then I could operate on your liver without you
ever knowing - heck I could remove it completely - regardless of any medical
training. can I assume you would rather keep control of who does what to your
liver?
$t = new T;
$t->insideClass = new T;
$t->insideClass->test = "testing!";
In this case, should __set() be called for both lines? Or only for the first?
I'd expect that, __set() be called on $t in the first line and
on the second line __get() to be called on $t and __set() on
object $t->insideClass. assuming that class T is defined as in my previous
post.
An array is exactly the same, except you cannot define a __set() method on it.
Anyway, I don't think this question belongs in internals, imho.
I'm not asking how it works. or how to use it but whether it's intended.
(something which STFW or RTFM doesn't enlighten me about) which is why I ask
the people that wrote the functionality (I figure they would know what the
intention is/was).
let me guess, you think it belongs on php-generals? well I'm asking this
question based on a discussion held there - and nobody offered any kind of
answer ... in fact I justed checked and one of the other guys on the thread in
question (subject: "Overloading Limitation- Can Someone Confirm?") now has
a variation of the code we were playing with that segfaults in 5.0.4 and causes
a 'FATAL: emalloc()' error in 5.1.1 (I don't have a newer version at hand
but the other guy reports very odd behaviour in (I assume in 5.1.2) the code in
question is:
<?php
class T {
private $array = array();
public function __get( $key ) {
echo "Getting $key\n";
return $this->array[$key];
}
public function __set( $key, $value ) {
echo "Setting $key\n";
$this->array[$key] = $value;
}
}
$t = new T;
$t->insideArray = array('a' => 'A', 'b' => 'B', 'c' => 'C');
foreach ($t->insideArray as $k => $v) {
$t->insideArray[$k] = null;
}
if (count($t->insideArray) > 0) {
foreach ($t->insideArray as $k => $v) {
echo $v;
}
}
var_dump($t);
?>
5.0.4 OUTPUT:
========================================
Setting insideArray
Getting insideArray
Getting insideArray
Getting insideArray
Getting insideArray
Getting insideArray
Segmentation fault
5.1.1 OUTPUT:
========================================
Setting insideArray
Getting insideArray
Getting insideArray
Getting insideArray
Getting insideArray
Getting insideArray
Getting insideArray
FATAL: emalloc(): Unable to allocate 1916888421 bytes
I have sneaking suspicion that that's not meant to happen.
rgds,
Jochem