I completely agree with Wez.
mbstring has very foundamental functionalities for multibyte users.
Multibyte users can 'not' build any useful application without mbstring.
We must understand there are so many users who are using multibyte
character encoding.
multibyte string functions for multibyte users has nealy same meaning
with string functions for singlebyte users.
If PHP lacks string functions, who can use PHP ?
I think mbstring enabled by default in PHP 4.3 is very good decision.
'function overloading' in mbstring is to make easier multibyte-aware
application, but, it is disabled by default.
I also agree with Wez, the official zend API for function overloading
is needed. I will change the implemantaion if some official API
is available.
Rui
On Fri, 8 Nov 2002 10:13:29 +0000
[EMAIL PROTECTED] (Wez Furlong) wrote:
> I see the known-good codeset conversion implementation as a *very* good
> reason to have mbstring enabled by default.
> (Just look at all the problems with iconv and recode on different systems
> out there).
>
> I agree that the magic features for lazy programmers (function overloading
> and transparent encoding) are slightly worrying, but they are disabled
> by default, and as I have said - I don't use those, but I do use the
> conversion functions and *that* configuration works just fine.
>
> The conversion functions are something that really should be there by
> default, as it allows people to write portable globalized scripts.
> Remember that a large majority of users are vhosted and have not control
> over the build of PHP. By not providing a reliable and portable
> codeset conversion API, we are holding back "the masses" from writing
> (and distributing) "killer apps" in PHP.
>
> Yes, I can enable mbstring at configure time, and yes, the CJK people
> can do likewise, but what about the rest of the world running from vhosts
> when they want to use unicode, quoted-printable, uu-encoding, <name of your
> favourite encoding here> encodings which are also supported by mbstring?
>
> We took the decision to enable it by default; let's not be short-sighted
> and disable it primarily out of ignorance (no offence intended).
>
> I've yet to see someone comment on my suggestions for a practical solution
> that would shut up both myself and the people advocating disabling it.
>
> --Wez.
--
-----------------------------------------------------
Rui Hirokawa <[EMAIL PROTECTED]>
<[EMAIL PROTECTED]>
--
PHP Development Mailing List <http://www.php.net/>
To unsubscribe, visit: http://www.php.net/unsub.php
