RE:

> -----Original Message----- > From: > Sent: None > Subject: > > > Date: Mon, 2 Sep 2002 06:42:15 -0500 (EST) From: "Sterling > Hughes" <sterling@bumblebury.com> > To: <imajes@php.net> > In-Reply-To: <MMEPJPGPACDMPGEEKFMKAEKBJAAA.imajes@php.net> > References: <MMEPJPGPACDMPGEEKFMKAEKBJAAA.imajes@php.net> > X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: > <wez@thebrainroom.com>, <php-dev@lists.php.net> > Reply-To: sterling@bumblebury.com > X-Mailer: SquirrelMail (version 1.2.4) MIME-Version: 1.0 > Content-Type: text/plain; charset=iso-8859-1 > Content-Transfer-Encoding: 8bit Subject: RE: [PHP-DEV] mbstring > > 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. no, i've never wanted to remove mbstring, i just would like to see it not enabled by default. 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? no i have used it, and yes, it's a useful extension, my point is that it's not a gold extension, and thus shouldn't be enabled by default. > > 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. xml/domxml aren't enabled by default. > 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... actually, Phil removed the --enable-mbstring configure option too -- _expecting_ mbstring not to be enabled anymore, hence my issue. > > 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 > -- sure, which is why it should be tested fully before enabled by default. > PHP Development Mailing List <http://www.php.net/> > To unsubscribe, visit: http://www.php.net/unsub.php > >