On Wed, 14 Mar 2012 14:55:17 +0100, jpauli <jpa...@php.net> wrote:
I would then propose to make mbstring compile time mandatory.
I'm completely against these kind of lazy solutions. Yes, let's add strong
coupling (already starting to smell) to one of the largest extensions and
make it compile time mandatory because it simplifies the implementation of
a dubiously useful feature like Zend multibyte. Remember PHP is sometimes
used in environments with limited memory/disk space.
Also mbstring takes a long time to build (relatively speaking). Just that
would be a strong argument against making it mandatory, at least for
people like me that compile PHP with --disable-all very frequently.
I'm against yet another global ini setting, I find the actual ini
settings confusing enough to add one more that would moreover reflect
mbstring one's (and add more and more confusion).
Why not turn ext/mbstring mandatory at compile time, for all future PHP
versions, like preg or spl are ?
We do need multibyte handling either. ZendEngine takes advantage of
mbstring for internal encoding as well, so I probably missed something as
why it is still possible to --disable-mbstring (or not add
--enable-mbstring) when compiling ? Has it a huge performance impact ?
mbstring hooks to basically all phases of PHP process/request
startup/shutdown. Some efforts were made to mitigate the impact of this in
5.4 (see e.g. r301068), but at least some impact is inevitable. Of course,
if you start enabling certain features of mbstring (zend multibyte hooks,
translation of input variables, function overload) then it starts to be
significant. However, there are other more compelling reasons not to make
it required (see above).
--
Gustavo Lopes
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
