Hello, I thought that this thread was over. Anyway, I finally made time to ban the functions that you broke from my site code. Since it gave me a lot of work and I feel that others could also benefit of the workarounds functions that I had to develop, I have just released a a class and some wrapper functions that provide the original behaviour of the broken functions.
The class is available here: http://phpclasses.UpperDesign.com/browse.html/package/404 . Downloading the class code does not require you to be subscribed. Later I will make a more complete announcement for those that are not subscribed to the PHP Classes Repository site. Zeev Suraski wrote: > > At 03:43 16/12/2001, Manuel Lemos wrote: > >So, there why keep giving more reasons to not upgrade? > > Because sometimes it's necessary. The way dirname() behaved was buggy and > unintended - it simply did not do what it was supposed to do. Perhaps Yes, but people where relying on the original behaviour. For instance, if you have a reloctable script and want to figure a sub-directory where you may have the graphic image files, you would use something like dirname(GetEnv("SCRIPT_NAME"))."/graphics/icon.gif". This stopped working when you broke dirname because if GetEnv("SCRIPT_NAME") is for instance "/index.php", dirname now returns "/" while before it returned "", so the expression above becomes //graphics/icon.gif . dirname never returned a path ending with / and that extra slash makes browsers not download the graphic image files as always breaking the behaviour of a site that is up and running for more than 2 years. > taking it to the extreme - it's kind of like pow(2,2) returning 4.01 > instead of 4. If such a bug existed in pow() and we fixed it, we wouldn't > have added an ini switch to turn it on/off. Except that I doubt that anybody would be relying in the behaviour because floating point math is not supposed to be accurate. BTW, I don't know if you are aware but arbitrary precision math functions are useless because it applies to the arguments the number of the decimal places that it should be applying only to results. There is a long standing bug rotten in the bug database waiting for somebody to fix it. You could fix such kinds of bugs to make arbitrary precision extension of any use instead of breaking the behaviour of functions that work as they did for 4 years. > register_globals is completely different. register_globals is a concept > which turned out to be very problematic, but people who bought into it It is always problematic. The difference is that you only realized recently, just like the behaviour of dirname and strtok that you broken. > should be allowed to go on using it. We also have to be a bit realistic > every now and then, and realize that the vast majority of PHP code today, > and we're talking dozens of millions of lines of code, relies on > register_globals being on. That's not true for dirname(). It doesn't mean Says who? Have you counted the number of people that are using dirname or strtok. > that BC breaks that only affect a small number of people should be taken > lightly - but obviously, this plays a significant role. Yeah, that is the same unrespectful conclusion as Rasmus, "it is just Manuel complaining". > >Admit it, you were not aware and not even documented the change that > >Andi made to the behaviour of a function that worked like that for 3 > >years. > > >Sure but they way it seems to me is that reporting the problem did not > >make any difference. So why bother reporting? > > It's your decision. Don't expect the dev-team to treat anything you put in > the bugs database as the 11th commandment. The dirname() example is > relatively unique, because the new behavior is not a problem, but a fixed > behavior which causes incompatibility. Incompatibility with what? Of something that never relied on it because the function never behaved before like the way it behaves when you fixed it? And what about strtok that was broken in November? What incompatibility it causes to whose PHP software? > >I am afraid that a lot of people simply do not bother to report > >problems, even when it affects their businesses, because they just get > >this kind of response and they certainly can use the time they spend > >making a useful report in things that can really result in something > >that the need. > > Don't worry so much. You're the first person to bring up this point in 5 > years :) Because most people don't know yet, as you broke the behaviour of two functions silently and did not document it anywhere! Also, when people will be aware, they as well not bother to tell you, especially if they know you track record of overuling people reports, even when they are made with consistent argumentation. Anyway, I really sorry for you because you have lately shown a very inconsistent attitude towards people that have invested a lot to help you on PHP/Zend development. While in Zend 2 list you have fought very hard people overuling their proposals to evolve PHP/Zend with your argument that it would break backwards compatibility, you come here and say it is ok to break the compatibility of long standing functions that always behaved that way for 4 years before you decided that it was ok to break them because "it was just Manuel" reporting. What credibility has a person that has such inconsistent attitude that nullifies the arguments of some key developers with the backwards compatibility argument, while at the same time you state elsewhere that argument is not that important?! No wonder why such key developers just turn their backs to you giving up attempting to cooperate and help you to improve a product from which you make business. Never mind, soon or later you will realize that your arrogance may be already causing harm to your business. 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]
