Can't you make it so that PHP internally uses a "nameless" variable in which
it stores the result of the __get() before it continues to do anything with
it? I may be too much of a rookie here, but it seems to me that that could
solve a lot of problems. You could even write to it (if you'd allow writing
to a nameless variable which doesn't make sense, but could be allowed).
Basically you'd internally be interpreting:
foreach ($obj->somevar as $foo => $bar)
{
}
as:
$_ = $obj->somevar;
foreach ($_ as $foo => $bar)
{
}
or would that present other problems I don't see? This doesn't solve it when
you wanna write to a virtual __get variable, but in a read-only situation, I
as a user wouldn't want to implement a __getRef(), it wouldn't make sense
from a user perspective.
- Ron
""Andi Gutmans"" <[EMAIL PROTECTED]> schreef in bericht
news:[EMAIL PROTECTED]
> We were considering supporting a __getRef() method. You could implement
> either or both of them and then the right thing would happen.
> Dmitry, Marcus - Besides having to come to a decision about this, is there
> any situation you guys discussed for which this would not work?
>
> Thx.
>
> Andi
>
>> -----Original Message-----
>> From: Dmitry Stogov [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, July 19, 2006 8:23 AM
>> To: internals@lists.php.net
>> Cc: Marcus Boerger; Andi Gutmans
>> Subject: RE: [PHP-DEV] PHP 5.2-dev "Cannot use array returned
>> from foo::__get('bar') in write context"
>>
>> __get() never worked in write context proper.
>> It just CAN NOT work proper, because __get() returns by value
>> (zval*), but modification requires address (zval**).
>> We have a lot of __get() related bugs because of this
>> situation in bugs.php.net.
>>
>> Month ago Marcus disabled usage of __get() in write context
>> and I am completely agree with him We cannot use E_STRICT for
>> this error and then SIGSEGV.
>>
>> Thanks. Dmitry.
>>
>>
>>
>>
>>
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
