RE: [PHP-DEV] mbstring

> > 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.