Dear Manuel, On Sun, 16 Dec 2001, Manuel Lemos wrote:
> What is the problem with 1000 switches? It is definitely better than > breaking backwards compatibility of functions that behaved like that for > 4 years. > > I just checked that there are 78 occorrences of use of strtok and 34 of > dirname in the code of PHP Classes repository. Many users use those > classes for a long time. I am going to release a warning so that the > authors either avoid those functions or the users not upgrade to PHP > 4.1.0 . Google finds even uses of strtok, and PHP: http://www.google.com/search?hl=en&q=strtok+php&btnG=Google+Search about 20100 results found. For dirname and PHP even more, 41100. So, this is a very big problem after, whouldn't you think? I'll go on with some more numbers; The numbers of lines in the PHP source code (as of the current CVS version): [derick@kossu php-4.2.0dev]$ find ./ -name "*.[ch]" -exec cat "{}" ";" | wc -l 330778 That's quite a lot to maintain, isn't it? Ok, more numbers: the number of commits in November 2001: 269, transposed to 4 years, that would be around 10000 commits. Around 10% of these commits changed behavior in PHP functions, around 40% of those break BC (that's Zeev's invented acronym for Backward Compability). (It's 40% because most of them are bugfixes, which correct wrong behavior, but they also break BC in that way). As you maybe know, Zeev is very stubborn regarding to BC breaking changes, and I totally afreed with (most) of it. Point one: BC is VERY important. Every PHP-deveveloper knows that, even James Moore. Now my point with those numbers I pulled out. With this number of commits, a lot of them being bugfixes, there is no way that BC is always maintained. Do you understand that? Point two: Fixing the code would have cost less time then writing lengthy e-mails to PHP, of reporting bugs. This may sounds as the head-in-the-sand method, but it's pure practical thing. To make it clear: I do not say that reporting this is a bad issue. The things you reported are documented in the manuel now, which we failed to do before. Point three: Upgrading from 4.0.0 to 4.0.1 is exactly of the same importance as upgrading from 4.0.6 to 4.1.0. To say it more clear NOT upgrading before was not the smartest thing to do, 4.0.0 has numerous security holes and bugs, which got fixed, oh no we break BC, in releases after 4.0.0. 4.1.0 is about 8 times more bugfree then 4.0.0, or should I say, we broke BC 8 times as much. Point four: PHP developers make mistakes, but PHP users too. There is no way with a code base of this size to make sure there is never a BC breaking change. Now, I hope this makes things a little clear for you. I won't waste more time on this stuff. Derick -- PHP Development 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]
