> I agree that allowing "=& new" and disallowing "return new" > by reference is inconsistent.
I'm so stubborn with this one because there might be good reasons if you're the mechanic lying under the car fixing the engine, but it does not make any sense if you just want to drive the car :) > But PHP4 is stable tree. We don't like different versions > with different behavior. I don't get that point :( If you make changes like the one from 4.3.12 to 4.4.0, why don't take back the notice with 4.4.1 if it makes no sense? Why's that "different behavior"? The point is that since 4.4.0 the "return new" triggers a notice although there's admittedly no good reason why it should do so. Conceptually/semantically, it does not make any sense, the required workaround is absurd, and, as I stated in my initial post, under some conditions (implementation details of the constructor) the notice does not even occur. I was just curious if there is any chance that this bug is corrected in 4.4.1 >:-). > In PHP5 "=& new" is deprecated, so I don't see any reason to > introduce "return new" by ref in PHP5. I was only talking about PHP4, because that is where people are struggling right now. I don't see where assigning by reference from "new" would make any sense at all with PHP5, apart from BC reasons. Of course, assigning new Objects() to parameters passed in by reference would make sense ;), but that is another story. Matthias -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
