BC was broken, this happens sometimes. The majority of the PHP Dev team agrees that strtok() should be POSIX compliant, so it is now, and forever will be.
Not being in NEWS/Changelog was an oversight/error, nobody is perfect. This not happening in the future is a desire of everyone. Also, it'll be nice when every BC break is clearly documented in one place, deprecations too. Your desires on the matter are shared by all, in that, allowing for seamless PHP upgrades is a good thing. Such breaks are very uncommon in the PHP world, you will find that some members want many more :)) This is documented now which is as best we can do at this point. That and clearly document all BC breaks in the future. I vow to help on the documentation end. Regards, Philip Olson On Mon, 14 Jan 2002, Manuel Lemos wrote: > Hello, > > I don't disagree, but the fact is that doesn't help anybody that used > the function and relied on its original behaviour that was there for 4 > years. > > As for being POSIX compliant, I don't think that POSIX states anything > about how PHP functions should behave, so I do not see where is the gain > of breaking this function, especially when making PHP strtok behave > exactly like C strtok is absolutely irrelevant I think for 99,9% of PHP > users because they don't use C in POSIX at all. As a side note, based on > the Web browser share distribution of the PHP Classes site, I think the > majority of PHP users come from Windows now, but I may be wrong. > > Anyway, if breaking the behaviour of a long standing function was bad, > what really made it worse the was fact that who has broken the function, > did not even have the decency to note down in the NEWS/ChangeLog, so > whoever plans to upgrade to PHP 4.1.0 could be warned and avoided > outages due to this silent backwards incompatible change. > > Documenting the new behaviour in the user manual does not help even if > it was not made much later after releasing PHP 4.1.0 like this change > that was only documented because there was a bug report much later after > the change was done. What happens is that careful developers tend to > take a look in the ChangeLog before installing a new version in a > production environment to avoid outages and misbehaviour cause by the > change in the broken function. Since it did not happen even until today, > nobody is being warned and depending on what the function is used for, > it may be causing data trashing of site databases until the developers > realize what happened. > > Don't you have a requirement in the PHP CODING STANDARDS file that makes > it mandatory for PHP developers to note down important changes? Not > having such requirement just allows messy development habits to > jeopardize PHP code quality. > > Before somebody decides to repress my opinion again, notice how I am > trying to be constructive by suggesting improvements in the quality of > PHP development process. Now you may put that gun down. :-) > > Regards, > Manuel Lemos -- PHP General Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
