Von: Derick Rethans [mailto:derick@php.net]
The point is that this requires really unlogic and silly
workarounds
like 'return $tmp =& 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.
I discussed this with Dmitry today and we agree that although
this is strange, we will not do any modifications here as PHP
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 =& 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?
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?
It's part of my talk "How PHP Ticks" at that conference.
Derick
--
Derick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org
I agree that allowing "=& new" and disallowing "return new" by reference is
inconsistent.
But PHP4 is stable tree. We don't like different versions with different
behavior.
In PHP5 "=& new" is deprecated, so I don't see any reason to introduce
"return new" by ref in PHP5.
Dmitry.
-----Original Message-----
From: Matthias Pigulla [mailto:mp@webfactory.de]
Sent: Monday, October 10, 2005 6:04 PM
To: internals@lists.php.net
Subject: AW: [PHP-DEV] return /* by reference */ new Foo() in PHP4Von: Derick Rethans [mailto:derick@php.net]
The point is that this requires really unlogic and silly
workarounds
like 'return $tmp =& 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.I discussed this with Dmitry today and we agree that although
this is strange, we will not do any modifications here as PHP
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 =& 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?