Hello, Derick Rethans wrote: > > 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.
Be serious! I think you do not know what is the PHP Classes repository. It is a very large repository of PHP classes of objects. It contains near 400 classes contributed by almost 200 PHP programmers. When I said I found that many occorrences of dirname and strtok uses, it was not something taken from a search engine, but rather grepping the actual source code of the classes that the users contributed. > 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? No, I am not sure if you are saying that James Moore is so incompetent that he did not realize that he was breaking backwards compatibility in the behaviour of a function that worked like that for 4 year, or you are saying that James Moore was aware that was breaking backwards compatibility of that function. Either way, mistakes were made and they affect people that depend on those functions to behave as they always did until somebody fixed them. I don't see anybody here admiting that it was a mistake. I wish people that made these mistakes at least would be humble enough to come up and admit that they made a mistake and will not do it again because it causes harm to people that depend on the behaviour that they broke. But no, instead all I see is a bunch of unprofessional excuses for not having to fix their mistake. > 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. Documenting a mistake does not make a better case to whoever made it. The right thing to do is to fix the mistake by assuring that there will be a backwards compatible way to enable the previous behaviour, even if the new behaviour is kept as default. > 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. You must be out of your mind if you expect people to upgrade on every little release just to realize if there was any mistake that the developers made by breaking backwards compatibility! The truth is that in the real world people have much more important things than watching PHP releases all the time. > 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. Sure, but there are two problems here: 1 - Some developers made a mistake and did not realized it when they made it. This should be a job for QA team to catch on time. 2 - After the mistakes were reported, the developers came up with all sorts of excuses to not admit that they made a mistake just to avoid having to fix the mistake. In this case, at least three things could have been done to control the portential damage that will be caused the developers that will upgrade to this version: a) Add an extra parameter to the functions in question that would somehow tell which behaviour the programs that depende on the functions need. A default value could be either to set the previous behaviour or the current depending on the reasoning of each case. b) Add a switch option to php.ini to determine which behaviour would the default. This could be a complement of the first alternative or not. c) Restore the original behaviour to the functions and add new functions that would exhibit the new behaviour. None of alternatives was taken, which means that the developer could not care less to whoever the backwards compatibility changes caused harm. I don't know what do you think, but this just shows the lack of professionalism of the people responsible for the mistakes. Regards, Manuel Lemos -- 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]
