Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:19537
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Sun, 9 Oct 2005 16:18:33 +0200
Message-ID: <00A2E2156BEE8446A81C8881AE117F192C15D7@companyweb>
Thread-Topic: [PHP-DEV] return /* by reference */ new Foo() in PHP4
Thread-Index: AcXM1UXGPPfEtp6vQ6eJji5EIemSAwAAg0dQ
To: <internals@lists.php.net>
Subject: AW: [PHP-DEV] return /* by reference */ new Foo() in PHP4
From: mp@webfactory.de ("Matthias Pigulla")

> The "return new..." is just a subset of the problem, but not=20
> the only one that is in wide use. For example, this is very common:
>=20
> function &getstuff($in)
> {
>   if ($in=3D=3D'ok')
>     return new MyObject();
>   else
>     return false; // this is the common line
> }
>=20
> The "false" obviously is not a variable that can be reference=20
> and it's even not an object, the _technically_ more correct=20
> answer would be "return null;". But both ways of doing it are=20
> are not the "new ..." problem AND throw a notice AND PHP=20
> should be able to silently know what to do. Boxing is an=20
> approach that covers all of the similar problems and I think=20
> it could easily be realizedsince I suppose PHP is already=20
> doing something similar to fix the memory leak problems.

Of course you're right. Seems my view was a little biased from looking
at my code only ;). The "return new" issue has the interesting side
effect that notices disappear depending on the constructor's
implementation details.

Many people will agree that your above code should work - when seen from
the "conceptual" point of view. It's a nasty side effect that because of
the way the PHP4 internals worked, you *had* to use the reference here.

Note that the following is yet another way of stating the same:=20

function &getstuff($in) {
	return ($in =3D=3D 'ok' ? new MyObject() : null);
}

The problem is that even if internally temp assignments are used to make
it "still work", how to separate the cases where notices are appropriate
("bad code") from those where they are not (because everything was
"legal")?

[Weak point - others will throw in that it has never been "legal" but
"only worked" :)]

> I don't understand the "only on PHP4": Why should PHP4 be=20
> more "advanced" than PHP5 regarding this issue? And more=20
> important: Why should the two versions differ in behaviour in=20
> such a basic point?

With PHP5 object handles, passing around references is really rare. If
you ported your code to make use of the new PHP5 features, you probably
won't see the whole reference passing-related problems at all (at least
not in places where you're only doing correct OO stuff).

Your example with PHP5:

#!/usr/bin/php5
<?php
  class Factory {
      function build($what) {
        if ($what =3D=3D 'a')
          return new Foo();
        else
          return null;
      }
  }
  =20
  class Foo {
  }
  =20
  var_dump($x =3D Factory::build('a'));
  var_dump($y =3D Factory::build('b'));
?>

gives:

object(Foo)#1 (0) {
}
NULL

Just as one would expect.

Matthias