Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:19519
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: Sat, 8 Oct 2005 21:57:01 +0200
Message-ID: <00A2E2156BEE8446A81C8881AE117F192C15D3@companyweb>
Thread-Topic: return /* by reference */ new Foo() in PHP4
Thread-Index: AcXMQnHT79NfX7Z+RCyAY/7iVzyUpw==
To: <internals@lists.php.net>
Subject: return /* by reference */ new Foo() in PHP4
From: mp@webfactory.de ("Matthias Pigulla")

Hi all,

first of all I do not want to set off yet another discussion about the
changes 4.4 brought. I do understand why the changes were necessary, and
in most of the cases, I would even endorse that pieces of code that
trigger the new "only variable..." waring are "bad code".

Anyways, to me it seems that there are two very common patterns in OOP
code that have problems with the new behaviours. The first one is
returning-by-reference a reference obtained from another function. This
was bug #33558 and has been fixed in 4.4.1RC1.

The other one is as to "return new ...", which is quite common (think of
factory methods!). Just as $x =3D& new Foo() needs to assign by ref to
make sure $x and $this (inside the constructor) point to the very same
instance, something like

function &createInstance() {
	return new Foo();
}

$x =3D& createInstance();

has to be done exectly like this with PHP4. Yes, I *do* understand that
it is evaluated as an expression and thus generates a warning.

The point is that this requires really unlogic and silly workarounds
like 'return $tmp =3D& new Foo()'. That forces people to touch stable
codebases; I find it comprehensible that they feel this is like passing
the engine internal problems to the php coders.=20

Even more disturbing, this does *not* generate a notice if inside Foo's
constructor, $this is assigned by reference to something else. Say, in
Foo's constructor, you have something like
$someObservableObj->registerObserver($this), where registerObserver (of
course) takes a reference and adds the observer to an array or something
like that. Thus, it depends on implementation internals of Foo's
constructor if "return new" - an implementation detail of a the factory!
- produces the notice.

The bug describing this is #33679, marked as bogus with no further
explanation.

So, in case of "return new", wouldn't it make sense to remove the
warning as the code is 'legal'? And please, don't start a new "it's just
a friendly notice" flame war.

Best regards,
Matthias