Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:19020
Return-Path: <colin@encode.net.au>
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Delivered-To: mailing list internals@lists.php.net
Received: (qmail 48345 invoked by uid 1010); 16 Sep 2005 00:55:35 -0000
Delivered-To: ezmlm-scan-internals@lists.php.net
Delivered-To: ezmlm-internals@lists.php.net
Received: (qmail 48329 invoked from network); 16 Sep 2005 00:55:35 -0000
Received: from unknown (HELO lists.php.net) (127.0.0.1)
  by localhost with SMTP; 16 Sep 2005 00:55:35 -0000
X-Host-Fingerprint: 220.245.213.234 220-245-213-234-act.tpgi.com.au  
Received: from ([220.245.213.234:22642] helo=localhost.localdomain)
	by pb1.pair.com (ecelerity 2.0 beta r(6323M)) with SMTP
	id 08/98-43379-6081A234 for <internals@lists.php.net>; Thu, 15 Sep 2005 20:55:34 -0400
Message-ID: <08.98.43379.6081A234@pb1.pair.com>
To: internals@lists.php.net
Date: Fri, 16 Sep 2005 10:55:22 +1000
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
References: <B0.E3.41173.75757234@pb1.pair.com>
In-Reply-To: <B0.E3.41173.75757234@pb1.pair.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Posted-By: 220.245.213.234
Subject: Re: Reference handling change and PHP 4.4.0
From: colin@encode.net.au (Colin Tucker)

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.