Hi!
Then do the right thing and make it PHP 5.3+ and namespace it right from the beginning.
I'd be glad to, but it has to work with 5.2. I would like to make it "ideal" way, but there are real world problems that needs to solve which intervene :)
The inconsistency is that one class, IntlDateFormatter, has a prefix. And the others do not.
Think of it as part of the name, not prefix. I'd like to keep it DateFormatter, but Derick wants "Date" word for himself :)
However, that means I would need to parse a locale string, extract only the information I need for a particular task, and pass a new locale string containing only the relevant information.
Well, most probably you don't need to parse it, you are the one that's composing it - I see no use case where you would get that complex kitchen-sink locale name from an external source. What you'd get probably is either the language name or the language ID, and maybe country name/ID - e.g. from configuration UI - or short locale name from DB, etc.
Like with the sort() method, it is completely wrong to expose implementational details through the API. And that's what this is doing.
Here I have little choice - either to allow it to segfault or to have checks. I wish ICU programmers weren't sloppy, but they are and purpose of this extension is to write ICU wrapper not to reimplement it. If you volunteer to write code that would allow to sanitize locale strings without imposing this limit - I am more than happy to accept it.
Right. IIRC, they accept objects, too. The NumberFormatter accepts only locale objects AFAIK.
I'm afraid you are confusing C and C++ API. -- Stanislav Malyshev, Zend Software Architect [EMAIL PROTECTED] http://www.zend.com/ (408)253-8829 MSN: [EMAIL PROTECTED] -- PHP Unicode & I18N Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
