> Wez, > > lets loose the crap here. I am happy to see mbstring in PHP! I have > used it too, when I needed multibyte support. > James, Let's stay consistent here. Your opinion changes more than Microsoft's .NET strategy... In your original message you stated that you wanted to remove mbstring. If you've changed your opinion fine, but don't chide Wez for responding to the opinion so forcefully expressed in your original message. Furthermore, you've said that you've never used mbstring extension and that mbstring is certainly not a gold extension in prior messages, what do you think Wez is going to respond too? > But you see, it's not really all that solid. It needs more work (hence > this apparent development outside of php.net). All I am saying is that > we should disable it by default in current releases. For PHP5, we > should have proper mbstring support that should probably also be > transparent; by that I mean I see no reason for it not to be as > standard functionality rather than an extension, if that is necessary. > _Every_ extension needs more work, a redesign, etc. The mbstring extension minus perhaps some of the newer features is quite solid, much more so than many of the other standard php extension (for example, xml and domxml), its being redesigned and reworked -- that's true, but that is imho just a matter of evolution and improvement. > I will let Phil know that he can update his errata to just removing the > one compile option -- however, he demonstrates a valid point: > unexpected behaviour sucks. This includes the building of modules that > you don't need. > Yes, unexpected behaviour does suck, but this is not unexpected... if you explicitly _enable_ a configuration option, and then it yields a certain documented behaviour, I would hardly call that unexpected... > if it were me, i'd rather just be able to build the bare-bones PHP > binary without an extensions, and compile others in as i needed them. > By enabling extensions by default, what you end up doing is increasing > the size of the end product... now that, in most cases, doesn't make a > difference, however for scenarios where you have very little space to > play with... having extensions compiled in by default that you don't > know about sucks. > > if we want to do some kind of auto-compile thing, then perhaps a script > which detects-and-compiles every extension could get stuck in /php4 for > those who were really lazy. > > As I see it, PHP was designed with speed and simplicity in mind. Having > the burden of a large number of extra modules compiled in by default > doesn't help, and deviates from this path. Compiling modules by default > which are buggy just compounds the problem. > As Zeev stated this doesn't really hurt speed, actually what you're suggesting would provide a larger speed hit (although not signifigant) than the current situation. As far as compiling in buggy modules -- yes, of course, that's stating the obvious. However mbstring is certainly not that buggy, unless you enable a further option, and that's debatable. >From reading Wez's message, I really don't see a reason to unbundle/unenable it -- as long as new development doesn't cause a new api (backwards compat), i wasn't aware before that it didn't cause any bc issues. I don't know how many people remember the bundling of XML with PHP4, but there were _quite_ a few kinks with that integration, causing segfaults and unexpected behaviour (especially when dealing with objects). When bundling a new extension, you should always expect a few kinks, with mbstring it seems that there are less than usual (we also had major problems with MySQL integration by the way...) -Sterling
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
