> This is a non-issue for phpDocumentor. All we need is at > least 6 months > to a year of lead time on the final decision in order to > adjust the code.
As I wrote, I happend to have Smarty and phpDocumentor checkouts at hand. I just checked a recently installed version of Mediawiki and they also use curlies (although only in a very few places). But at least this should be a good argument against "nobody out there is using them anyway". Let alone all the other good reasons. Oh, btw, phpMyAdmin also uses them. > However, it is obvious that a script is needed that iterates over a > script and changes things that are easy to fix like the > $a{blah} one. I Yeah, someone just started a thread regarding this idea. As to this special case, maybe you can automagically find exactly the affected or possibly affected lines of code and update them. But more generally, I think writing the "general purpose automagical updater" is infeasible because sooner or later you'll run into issues you cannot detect or fix with a lint-type analysis but that require real execution of all possible code paths (e.g. stricter function argument parsing, changes in handling of NULL when used in array functions, passing non-array to array_merge...). Even worse, something like reordering function arguments (as somebody mentioned shortly mentioned here?) can only be detected by having specifically written test cases at hand. > 2) be thankful this is transparent enough that we can have > enough lead > time to make small changes to legacy scripts as needed - this > is why the > E_STRICT is added to PHP 5.1 now. Would you prefer a sudden break in > PHP 6 without any warning? Apart from that nobody has given a sound reason yet (maybe I missed it) why it needs a change at all, as we know from recent history there are people out there who happen to get notices on their sites and consider that "breaking things". So for these people, this issue by itself is why things might "break" as soon as their hosters upgrade to 5.1. > 3) ALWAYS test RCs of releases when they come out with our critical > applications and note any breaks here, to determine whether they are > bugs or intentional changes in PHP. That was yet another thing I felt disturbing and complained about but noone has commented on that yet - why do you need to make changes like this one in RC5? Every change that is later than an RC1 is more likely to be missed by people, even those who are diligently testing their stuff. Additionally, RC5 is damn pretty close to a release and that puts unnecessary pressure on people to get it fixed. Sorry for being so annoying. -mp. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php