ID: 21702 Updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Open +Status: Wont fix Bug Type: Scripting Engine problem Operating System: Any PHP Version: Any
Previous Comments: ------------------------------------------------------------------------ [2003-01-22 00:21:28] [EMAIL PROTECTED] I don't want to cause too much of a fuss about this -- but after looking at it myself I do think it has some merit... There is no reason why by simply adding a reference to the array in question the foreach() statement should suddenly change it's behavior. I've seen "incorrect" behaviors in ZE not be treated as bogus before (such as when working with bit operations) -- this seems to fall under a simliar category. At the very least, it's a feature/change request. ------------------------------------------------------------------------ [2003-01-21 23:11:38] [EMAIL PROTECTED] 1. No 2. Yes 3. No ------------------------------------------------------------------------ [2003-01-21 23:01:40] [EMAIL PROTECTED] Reopening due to lack of evidence that this is not a bug. Derick has not answered my email, he has not provided an explanation in his bug-closing comment, I have not found any discussion about this in the php-dev mailing list archive, and until recently, the behaviour has been in direct contradiction with the manual (while now the manual is unclear). Therefore, I have to assume that the statement "this is not a bug" is unfounded. I thought that this was an open source project? And even if the current behaviour was really intended, the documentation needs to be clarified. Let me ask three questions: 1) Is the current behaviour optimal? 2) If not, is it too late to correct it (because of backward compatibility)? 3) If not, is it important enough to invest time in it? My opinion: no, no, depends on who's time is in question. ;-) ------------------------------------------------------------------------ [2003-01-17 12:12:19] [EMAIL PROTECTED] Thank you for taking the time to write to us, but this is not a bug. Please double-check the documentation available at http://www.php.net/manual/ and the instructions on how to report a bug at http://bugs.php.net/how-to-report.php not a bug ------------------------------------------------------------------------ [2003-01-17 11:55:33] [EMAIL PROTECTED] > No matter what you call this, as a convention of open-source > projects, documentation is generally supposed to come up > after coding stuff. "Supposed to"? I hope not. It does, usually, that's true. But in this case, there _was_ documentation, and the program doesn't conform to it. And we're talking about language semantics, not something insignificant like configuration options. > the codes determine the design Tell me which programming language interpreter or compiler was created this way? As for the other nastiness example that you provided, it certainly does seem nasty. Should that mean "there is at least another one nastiness, so that is a good enough excuse to make ad-hoc language design decisions"? I don't get it. And yes, a language design decision it is, and it must be made. Either we correct the documentation (it's still not completely clear, though at least it's not so undoubtedly incorrect as two months ago), or we correct the implementation. Judging by the lack of interest so far (this is only the second bug report that I know of, and the docs have been incorrect for more than two years), not many people are relying on the current (broken) behaviour. (Anyway, why would anyone rely on such a thing?) Thus, we have a great opportunity to do the Right Thing! Anyway, I'm leaving for the weekend right now, so don't close this bug before I can have another round at it on Monday, ok? ;-) ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at http://bugs.php.net/21702 -- Edit this bug report at http://bugs.php.net/?id=21702&edit=1
