ID: 21702 User updated by: [EMAIL PROTECTED] Reported By: [EMAIL PROTECTED] -Status: Bogus +Status: Open Bug Type: Scripting Engine problem Operating System: Any PHP Version: Any New Comment:
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. ;-) Previous Comments: ------------------------------------------------------------------------ [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? ;-) ------------------------------------------------------------------------ [2003-01-17 10:22:30] [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. In other words, the codes determine the design, and the documents are often elusive as there are some cases where they don't reflect the actual behaviour. Regarding the nastiness of references, it's special not only for foreach, but also for the following case. <pre><?php $foo = array('test'); $bar = &$foo[0]; print "{$foo[0]}\n"; function test($foo) { $foo[0] = '???'; } test($foo); print "{$foo[0]}\n"; ?></pre> Surprisingly, this script results in ------ test ??? ------ For more about this, see bug #20993 (this is also marked as a doc-problem). ------------------------------------------------------------------------ [2003-01-17 08:27:40] [EMAIL PROTECTED] > Although I admit that the behaviour is quite inconsistent, > we won't fix this anyway because the issue's all up to the > language design. Well, I dunno. In bug #8353, [EMAIL PROTECTED] says: "...the following note exists in the foreach() entry of the manual and has for over two years: Note: Also note that foreach operates on a copy of the specified array, not the array itself, therefore the array pointer is not modified as with the each() construct and changes to the array element returned are not reflected in the original array." The documentation has been changed very recently. To me, this seems like re-defining the language. (Or "changing the rules in the middle of the game", if you prefer.) Instead of fixing the bug, you say it's a feature and change the docs. That seems very Microsoft-ish. Plus, such a language construct is inconsistent, unintuitive and seriously limited in usability. > foreach statement always makes use of a copy of the given > array instead of the original itself unless the array is a > reference or has a reference. The "makes a copy" part is in the docs, and is what I expect. The "unless..." part is (still) not in the docs and seems non-sensical. In fact, in "What References Do", the manual says about what happens after "$a =& $b" the following: "Note: $a and $b are completely equal here, that's not $a is pointing to $b or vice versa, that's $a and $b pointing to the same place." Nowhere in the manual it says that references are special. It just says that a reference is another name for the same variable. I don't see why foreach treats them specially. Note that I'm not advocating for changing the documentation; I'm actually strongly supporting what the documentation says and has said for a long time, and that means foreach is what needs to be changed. BTW, does the "unless..." part of the above quotation mean that when I do $a =& $b; foreach ($a as $elem) $elem->change_self(); it will work - because foreach is not working with a copy of the array? I suppose not, because it will surely make a copy of each element, right? Can I then coerce it by first making an array of references to every element, so that foreach will treat the elements specially? Wow, this is even nastier than I thought! ;-) Let's make a vote on the front page of php.net: - Foreach Pro-consistency Front program: repair foreach, return docs to previous state - Conservative Foreach Party program: keep foreach as is, make docs even more clear ------------------------------------------------------------------------ [2003-01-17 07:36:09] [EMAIL PROTECTED] Although I admit that the behaviour is quite inconsistent, we won't fix this anyway because the issue's all up to the language design. > Also, I find this very inconsistent. I didn't mention it in the original > description, but you know what? When you nest two foreach's using the > VERY SAME variable, it magically works! How is it possible that two > references to the same variable are somehow more equivalent than the > variable is to itself??? :-o Well, it looks like a magic. To say more precisely, foreach statement always makes use of a copy of the given array instead of the original itself unless the array is a reference or has a reference. That's the reason you could get along with nested foreach loops in general case. Thus the following while loop (A) is an equivalent to (B). <?php /* A */ $copy_foo = $a; reset($copy_foo); while (list(,$b) = each($copy_foo)) { $copy_bar = $a; reset($copy_bar); while (list(,$c) = each($copy_bar)) { print $c; } } ?> <?php /* B */ $a = array(1, 2); foreach ($a as $b) { foreach ($a as $c) { print $c; } } ?> Related bugs: http://bugs.php.net/bug.php?id=8353 ------------------------------------------------------------------------ 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
