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:[EMAIL PROTECTED] > Sent: Monday, October 10, 2005 6:04 PM > To: internals@lists.php.net > Subject: AW: [PHP-DEV] return /* by reference */ new Foo() in PHP4 > > > > > Von: Derick Rethans [mailto:[EMAIL PROTECTED] > > > On Sat, 8 Oct 2005, Matthias Pigulla wrote: > > > 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? > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
