On November 13, 2002 07:50 am, Melvyn Sopacua wrote: > FWIW: > * If this is ever going to make core as a part of PHP's i18n efforts, you > are going to have to deal with the 'unseen' at some point. You are not > going to identify them, by testing it within a select group. For this > reason, the userbase is always the guinnea-pig with every new feature > in a release.
If mbstring proves to be as popular as some people say many people will take a chance and enable the extension while compiling given the size of PHP user base that should be more then enough people to discover bugs in the extension. However, there is no need to put some 2 million (or whatever the latest netcraft data is) hosts running PHP at risk by enabling it by default. Unfortunately every extension has bugs, but usually such bugs do not affect PHP overall performance, mbstring is different, a bug in it can affect PHP behavior. Because of this I believe we need exercise extreme caution before even considering enabling it by default. > > * Getting real bug reports is a good thing(tm). Breaking compilation > because of sloppy symbol protections sucks(r). The number of bugs should > not be a factor in this scenario, because once it becomes core, you're > gonna have to deal with them anyway. Given prior history, when an extension has many bugs or is being heavily modified it was/is marked experimental and kept so several months even after the development was halted and bugs were addressed. Why an important extension like mbstring should be different? > * Enabling by default for 4.3.0 is actually the best point in time, unless > there's going to be a 4.4.0. You don't want this to be done in 5.0.0, > because the new OO layer, other new features and especially BC-breaking > issues will have to be focused on. (I'm not saying PHP 5 is intending to > break BC - just that there is a high probability issues arrise, which > we're not foreseeable). I think there is a >60% chance that they'll be further 4.3.X releases after 4.3.0 simply because this release represents a fair number of large changes and most likely will require several bug fixing releases. It is even remotly possible that 4.4.X may happen, but I am in no position to make such promises so, this is something I can only make educated guesses on. > A x.x.0 release is the best release to do it in, because people who > demand a high level of stability already will skip it and still it will > have a large enough audience to flush out the bugs nobody thought of. Sure, but if the people who try it get burnt by the mbstring extension, you can be sure that in the next release at least half of them will disable it straight off. And if these people are hosting providers, they'll refuse the turn it on for their customers because they would consider it a hindrance to the stability of their PHP. You are going to accomplish the exact opposite of what you've set out to do. > All in all - I think we should enable the parts mentioned by Wez, in RC1. > The default behavior should be "it's compiled in, but doesn't impact any > functions". > > If there is a large number of distinct bug reports, then it's obvious the > extension is not mature enough for it and because of the schedule (not the > number) it should be disabled in the final release I am lazy and I am sure many other people are too, certain features like overloading make life rather simple in that regard. You can be sure many people who are as lazy as I am will turn it on. Because to them it would be an important feature. Consider if a person is trying to make large, existing application support multi-byte, with overload they can avoid changing a large chunks of their code, they'll try it. If it does not work, many will simply drop mbstring because for all its wonderful functionality, it does not work as advertised. So, saying lets enable part A because it is stable and disable part B and C, just does not work. It is either all or nothing. Ilia -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
