Matthias Pigulla schrieb: > 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.
Throwing a notice here is complete nonsense. All thinkable languages use this coding style of "return new". If I return a reference to something new and there's no name for it yet then a temporary internal name for it has to be created until the object is given a real name or it is no longer referenced. This is valid for all "only variables can be returned by reference" cases where the object originates from userspace. > The bug describing this is #33679, marked as bogus with no further > explanation. I had a similar experience with http://bugs.php.net/bug.php?id=34783 which tells that with objects implementing ArrayAccess usage of $object['index_using_the_interface']['subindex_for_index_that_is_array'] can't be made to work since 5.1. First of all, "won't fix" would have been the correct response instead of "bogus" since a very similar problem was marked "won't fix". But there are two things very problematic with this: - This worked perfectly in 5.0.3 (I didn't use 5.0.4 so I don't know how 5.0.4 reacts). - You mustn't create an interface that pretends to mimic arrays and then make it impossible to fully simulate array behaviour. The explanation for marking the bug bogus was "IT IS IMPOSSIBLE TO HAVE ARRAYACCESS DEAL WITH REFERENCES.". Then why did this work in 5.0.3? Okay, perhaps because of a more lax way of parsing the interface definition. But then this definition was false in the first place and should be corrected to support references. And if this is out of question then at least some workaround has to be implemented to support the sub-array-syntax as this has nothing to do with references from a user's point of view. Think a few years into the future with ArrayAccess implementations all over the place and people trying to use them as arrays. Because these implementations are hidden in frameworks people will totally freak out because sometimes $a[1][2] works and sometimes they get a totally incomprehensible "Objects used as arrays in post/pre increment/decrement must return values by reference" as fatal error when using such simple code. If they can't make the ArrayAccess to work like real arrays then it would be a better way to completely dump it (or lock it against implementation in userspace) instead of letting inconsistent behaviour creep into the language concepts. But, like with your bug, the bogusing bot is quite quick these days where just CLOSING mem leaks has priority over FIXING them from a PHP user's point of view. Perhaps the PHP coders should keep _all_ PHP code from being executed as this would certainly close every thinkable leak. It's not wise having users turn their back on key features of 5.x when the switch from 4.x to 5.x hasn't even really started. AllOLLi ____________ "Your DNA must cry itself to sleep at night." [Coupling] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
