Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:19024
Return-Path: <truth@proposaltech.com>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 19018 invoked by uid 1010); 16 Sep 2005 05:08:42 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 19003 invoked from network); 16 Sep 2005 05:08:42 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 16 Sep 2005 05:08:42 -0000
X-Host-Fingerprint: 68.142.198.200 smtp101.sbc.mail.mud.yahoo.com  
Received: from ([68.142.198.200:42435] helo=smtp101.sbc.mail.mud.yahoo.com)
	by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP
	id FD/4D-43379-A535A234 for <internals@lists.php.net>; Fri, 16 Sep 2005 01:08:42 -0400
Received: (qmail 92329 invoked from network); 16 Sep 2005 05:08:38 -0000
Received: from unknown (HELO 192.168.2.101) (jabouillei@71.136.47.251 with plain)
	by smtp101.sbc.mail.mud.yahoo.com with SMTP; 16 Sep 2005 05:08:38 -0000
Reply-To: truth@proposaltech.com
To: internals@lists.php.net
In-Reply-To: <08.98.43379.6081A234@pb1.pair.com>
References: <B0.E3.41173.75757234@pb1.pair.com>
	<08.98.43379.6081A234@pb1.pair.com>
Content-Type: text/plain
Date: Thu, 15 Sep 2005 22:08:33 -0700
Message-ID: <1126847313.15244.18.camel@notebook>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.1 
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] Re: Reference handling change and PHP 4.4.0
From: truth@proposaltech.com (Todd Ruth)

Aha!  That was the inspiration I needed to get the right
combination of "&"s.  The following bit of code behaves
differently under 4.3 vs 4.4:

<?php
function f(&$a) { return $a; }
$x = array('a','b','c');
foreach (array_keys($x) as $k) {
   // I think the following line disconnects $y in 4.3
   // but leaves $y connected in 4.4
   $y =& f($x[$k]);
   $z[] =& $y;
}
var_dump($x);
var_dump($z);
?>

My guess would be that in 4.3 the engine tries to do the
reference even though it may be dangerous.  That would
"disconnect" $y from the previous $z[].  4.4 knows the
reference is impossible and leaves $y connected to the
previous $z[].  Is that analysis correct, engine gurus?

Thanks, Colin!

- Todd

On Fri, 2005-09-16 at 10:55 +1000, Colin Tucker wrote:
> Hello again,
> 
> Wow, this thread generated more heat than I thought it would, I 
> basically just wanted to know the reasoning behind making the change to 
> PHP4, unfortunate I guess for all involved that it went downhill.  I 
> have learned much in the past few days, at any rate.
> 
> As mentioned, my code actually broke following the switch to 4.4.0, in 
> addition to logging hundreds of E_NOTICE errors.  It's taken me some 
> time to track down where it's going wrong, but I think I've found out 
> the culprits involved.  It's complicated, I'll try to explain it all.
> 
> The problem was related to components of my web app framework (which is 
> similar to Struts, and incidently, now being phased out for a MUCH more 
> lightweight, PHP5-based framework), in particular, an array of 
> attributes, view helper classes and the creation of DAOs (data access 
> objects) at runtime via XML configuration, which would look like this:
> 
> <daos>
>   <dao name="dao.freight"
>        class="FreightDAO"
>        component="Generic/Commerce/DAO/FreightDAO.php" />
>   <dao name="dao.customer"
>        class="CustomerDAO"
>        component="Generic/Commerce/DAO/CustomerDAO.php" />
>   <dao name="dao.order.status"
>        class="OrderStatusDAO"
>        component="Generic/Commerce/DAO/OrderStatusDAO.php" />
> </daos>
> 
> This XML would be parsed and the relevant DAO instances would be created 
> and recorded in attribute scope for the current application module 
> instance.  For each dao node, the following code would be called (where 
> $daoClass and $daoComponent are extracted from the XML attributes):
> 
> $dao =& $this->_createDAO($daoClass,$daoComponent);
> 
> if ($dao)
> {
>     $this->module->setAttributeByReference($name,$dao);
> }
> 
> Notice it assigns by reference, however I discovered that the 
> _createDAO() method was not *returning* by reference:
> 
> function _createDAO($daoClass=null,$daoComponent=null)
> {
> 
> // Obtain Database Object:
> 
>     $database =& $this->module->findDatabase();
> 
>     if (is_null($database))
>     {
>        trigger_error($this->error(ERROR_DB_COULD_NOT_OBTAIN));
>     }
>     else
>     {
> 
>     // Obtain Database Connection:
> 
>        $connection =& $database->getConnection();
> 
>        if (is_null($connection))
>        {
>           trigger_error($this->error(ERROR_DB_COULD_NOT_CONNECT));
>        }
>        else
>        {
> 
>        // Create DAO Instance:
> 
>           $cmp =& new ClassComponent($daoClass,$daoComponent);
> 
>           $dao =& $cmp->getInstance();
> 
>           if ($dao)
>           {
>              $dao->setConnectionByReference($connection);
> 
>              return $dao;
>           }
>        }
>     }
> 
>     return NULL;
> 
> }
> 
> What was happening under PHP 4.4.0 is when the newly created DAO was 
> added to the module as an attribute (setAttributeByReference), a new 
> attribute would be created, but ALL existing DAOs in the attribute scope 
> would become the newly added DAO, for example:
> 
> (create and set the dao.freight attribute):
> 
> attributes (array)
> {
>    [dao.freight] => FreightDAO Object
> }
> 
> (create and set the dao.customer attribute):
> 
> attributes (array)
> {
>    [dao.freight] => CustomerDAO Object
>    [dao.customer] => CustomerDAO Object
> }
> 
> (create and set the dao.order.status attribute):
> 
> attributes (array)
> {
>    [dao.freight] => OrderStatusDAO Object
>    [dao.customer] => OrderStatusDAO Object
>    [dao.order.status] => OrderStatusDAO Object
> }
> 
> Simply by adding the ampersand to the _createDAO() method, like so:
> 
> function &_createDAO($daoClass=null,$daoComponent=null)
> {
> }
> 
> ...rectified the problem (however did not make hundreds of E_NOTICE's 
> disappear, of course ;)).
> 
> The question is, why did this problem not occur before 4.4.0?  Is this 
> an example of the "memory corruption"?
> 
> Regards,
> 
> Colin.
>