Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:19550
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: Mon, 10 Oct 2005 16:04:11 +0200
Message-ID: <00A2E2156BEE8446A81C8881AE117F192C1603@companyweb>
Thread-Topic: [PHP-DEV] return /* by reference */ new Foo() in PHP4
Thread-Index: AcXNlTBHNK6nsWINTKeC3DmnYp0gQAAACHig
To: <internals@lists.php.net>
Subject: AW: [PHP-DEV] return /* by reference */ new Foo() in PHP4
From: mp@webfactory.de ("Matthias Pigulla")


> Von: Derick Rethans [mailto:derick@php.net]=20

> On Sat, 8 Oct 2005, Matthias Pigulla wrote:
> > The point is that this requires really unlogic and silly=20
> > workarounds=20
> > like 'return $tmp =3D& new Foo()'. That forces people to touch =
stable=20
> > codebases; I find it comprehensible that they feel this is like=20
> > passing the engine internal problems to the php coders.

> I discussed this with Dmitry today and we agree that although=20
> this is strange, we will not do any modifications here as PHP=20
> 4.4. is stable and we don't want to risk breaking things.

<sarcasm-please-ignore> Yeah, keep 4.4 stable and make sure it does not
break things. Delegate these problems to the developers of PHP code >:)
</sarcasm-please-ignore>

Sorry. I know you put big effort into recovering from this kind of
problems and did not have fun with it either. So, this is something that
is too complex to handle in the engine? I mean, if you can detect that
what follows "return" is a (php level) function call that returns a
reference, why can't you handle "new" the same way?

Explain someone (maybe new to PHP) why "new Foo()" creates a "thing"
that can be referenced, as you can assign it by ref like $a =3D& new
Foo(). But you cannot return the very same referencable "thing" from a
function and make the assignment up one level in the call stack?

Yes I know - it's just a notice. But it hurts to add hot air (semantic
NULLs) to large, stable codebases just to make inappropriate notices go
away again.

Matthias

PS. Anyone ever thought about explaining the whole reference-related
decisions on the upcoming International PHP Conference? Maybe that could
help to gain understanding as to why the changes were necessary... Maybe
also give a statement as to possible breaks in BC with the advent of
PHP6?

I have the impression that a lot of people out there are frustrated and
unsure as to why they should fix PHP4 code to rewrite it for PHP5 and to
port that to PHP6 in a few years... Why not stick to
<hyped-language-goes-here> right now?