> > >> -----Original Message----- >> From: >> Sent: None >> Subject: >> >> >> Date: Mon, 2 Sep 2002 06:42:15 -0500 (EST) From: "Sterling >> Hughes" <[EMAIL PROTECTED]> >> To: <[EMAIL PROTECTED]> >> In-Reply-To: <[EMAIL PROTECTED]> >> References: <[EMAIL PROTECTED]> >> X-Priority: 3 Importance: Normal X-MSMail-Priority: Normal Cc: >> <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> >> Reply-To: [EMAIL PROTECTED] >> 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. xml is, it has been since the PHP 4.0 betas > >> 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. > I'm going to make a generalization, and say that most php users are not illiterate like Phil, and can in fact, should the need arise, read the documentation. Perhaps if Phil has further problems he can get a text-voice software that will read him the documentation outloud. These programs won't properly pronounce my sarcasm, but it should be a good start. > > >> 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. > And your opinion is that they are not _fully_ tested, and stable to the point that you'd like it? What exactly do you have in the way of outstanding issues, what do you think should be better? Why is mbstring not stable enough for you -- where are the problems that you're having?
-- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
