So are you saying that php will automatically issue setlocale() calls?
e.g.:
<?php
i18n_loc_set_default('pt_PT'); // or whatever that is called these days
//now it magically calls setlocale('pt_PT', 'pt_PT.iso8859-1',
'portuguese'); -- linux/bsd/windows
echo preg_match('/^\w+$/', "àáãçêõ"); //prints 1?
?>
Nuno,
The idea is that while internal libs will use it, PHP will do all the
user-locale handling internally.
On 25-Jan-07, at 9:52 AM, Nuno Lopes wrote:
PHP needs locale insensitive strcasecmp() or your developers will
continue
hitting string comparison issues in Turkish and Azerbaijani. Ilia
patched
it in timezone parsing code. Some day other strcasecmp will pop in
other
place.
Switching locale everytime you want to compare strings is a hack and
not a
bug fix.
Its a solution that works. There are very few instances where such
behavior is needed and in php6 it won't be relevant anyway since posix
locales will not be used.
This is not true at all.. I even think this is a big misconception of
PHP 6.
Although this has nothing to do with the issue mentioned above, we will
still need setlocale() in PHP 6 because of externals libs. Even the
bundled PCRE uses locales, and that is very handful (e.g.
locale-dependent '\w'). So, POSIX locales will be deprecated for string
handling, date formatting and such things, but they will still be used
by external libs.
Nuno
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
