Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:15264
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Message-ID: <5.1.0.14.2.20050305175824.020f61f0@localhost>
Date: Sat, 05 Mar 2005 18:00:16 -0800
To: yml@dtlink.com,internals@lists.php.net
In-Reply-To: <64479.207.192.181.138.1110074493.squirrel@secure.fieldpost
	.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Subject: Re: [PHP-DEV] PHP 5.0.3 losing $this - followup.
From: andi@zend.com (Andi Gutmans)
References: <64479.207.192.181.138.1110074493.squirrel@secure.fieldpost.com>

Hi Jermo,

Are you getting an error message if you set E_STRICT?
Actually this code is not supposed to work in the first place. The reason 
is that you are only allowed to return variables by reference (like in many 
other languages). There was a bug in PHP 4 and early versions of PHP 5 
which allowed you to get around this. In PHP, if you put parentheses around 
variables like you did, that becomes a read-only expression, very much like 
(2+2). There is really no way of resolving that behavior. We are supposed 
to print a warning or strict message when this happens but I can't check it 
right now.
What is the behavior you are getting?

Andi


At 09:01 PM 3/5/2005 -0500, Yermo Lamers wrote:

>Thanks to michaels (at) crye-leike.com for the followup. He produced a
>much shorter version of the code that produces the same result:
>
><?php
>class Foo {
>   function &getThis() {
>     return( $this );
>   }
>   function destroyThis() {
>     $baz =& $this->getThis();
>   }
>}
>$bar = new Foo();
>$bar->destroyThis();
>var_dump($bar);
>?>
>
>Interestingly if you change the return( $this ) in &getThis() to return
>$this; the bug is reproduced. Weird, parentheses making the difference.
>
>I had thought it was related to the depth of subclasses and the particular
>arrangement of members; i.e. classic buffer overrun symptoms.
>
>So I stand corrected.
>
>As a followup question, if I have a large body of code for which I cannot
>produce a small test case what's the recommended approach to tracking it
>down .. pass it by here before posting the bug report? I've still got that
>weird PHP 4.3.10 bug that should also get resolved.
>
>----------------------------------------------------------------------------
>DTLink Software                                 http://www.dtlink.com
>        Desktop Software and Web Applications
>----------------------------------------------------------------------------
>
>--
>PHP Internals - PHP Runtime Development Mailing List
>To unsubscribe, visit: http://www.php.net/unsub.php