> > 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.
> 
> No, you can always disable those extensions.  The default extensions were
> *voted* in for a reason.
>

Still, I think it makes more sense to enable, not disable. What extensions are enabled 
by default anyhow?  I am not aware of a list. Perhaps that's why i get odd errors when 
working with php, because there are extensions i didn't expect built in.
 
> > Compiling modules by default which are
> > buggy just compounds the problem.
> 
> Yes, but the bug was only present in an advanced optional feature 
> that would
> cause "unexpected behaviour" for non-mbstring aware people anyway.
> *and it has already been fixed a number of weeks ago*
> 
> As I've said, mbstring is very stable in it's default configuration - the
> codebase has been around for years and tested to death by a very dedicated
> i18n team *in production*.
> 
> The "development" you keep referring to is part of a streamable filter
> *add-on* that does not change the existing code that people rely on.
> 
maybe i'm jaded against mbstring here, but i experienced two unexpected crashes which 
i traced back to mbstring, but with no real cause that i could find, as well as 
watching the cvs commits -- and also wondering why on earth they feel they want to 
work on mbstring @ sf.jp. CVS is quite capable of maintaining code (hence branches).

> Why don't you test the current CVS to see if it still has a problem,
> if it does, lets fix it.
> 
I will do that.

> Please don't take a step backwards by disabling this extension by default
> just because you are afraid that people can abuse advanced options.

I'm not taking a step backwards, just trying to remove the potential for confusion. If 
people think that register_globals is confusing, and causes issues, then we should 
also not build stuff by default. I *HATE* it when I don't know what's being built.


--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to