> -----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.
> 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
>
>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
