Hi Stan, On Tue, Apr 8, 2008 at 7:04 PM, Stanislav Malyshev <[EMAIL PROTECTED]> wrote: > > The ICU API solves this issue nicely using the current locale. It > > would be easier to work with the intl API if the same principle was > > used. Add a Locale::setDefault() and Locale::getDefault(). > > > > You can use default locale, of course, and Locale class already has these > functions. http://docs.php.net/manual/en/class.locale.php
I did not find a way to do it in the manual or in the code. How do I set in PHP? And how is it possible to use it as default for all further calls (no matter which class/method)? > > The argument order for the constructors/factories should be change to > > allow that. The locale argument has to be optional (and moved as 2nd+ > > argument). > > > > I'm afraid that wouldn't work since functions have variable number of > arguments and we want consistent API across all modules. That's why I would prefer an array (as named arguments). The keys (names) are easy to remember. You can even support both. I'm ready to provide a patch to support array as input (with default values support) if we agree on that. > > Arguments order may be confusing and hard to remember. However their > > > > Like "locale goes first"? The locale as 1st argument always looked weird to me when I was writing my test code. The reason is certainly because of the default locale not being set or used. As it is possible (if I understand you correctly) I don't see why it has to be as first argument, one will always has to pass it (NULL/"" or a valid locale id). > > 4. Support of Date Object, they are the standard DateTime type in PHP. > > > > Planned to be done later - if anybody wants to contribute now, please do. > It is indeed very important, we just don't have somebody to do it right now. If right now is not within days but within 2 weeks, I can try to do it. But I first like to hear Derick's idea on the topic before. Please let us know your thoughts (wiki?) about this topic, it will certainly spare us some precious time. > > 5. Error management is rather unintuitive. I can't imagine to have to > > check the error code after each call. Exceptions can greatly improve > > > > Like 99% people do with 99% functions in PHP? You must be really suffering > not writing code in Java :) Where did you get these numbers? For what I see nowadays, it is more a high percentage with OO for everything but some basic helpers. However, the point is not about OO or not OO but to do not duplicate the API without any gain. Locale::foo() is as easy to write or read than locale_foo(). > > 6. What's about a __toString implementation when possible. It may be > > > > If you can propose good toString - and especially if you have volunteer to > implement it :) - why not? We didn't have good use for toString, but if you > find one - welcome. I will think about it a bit more. But that will rock to have it :) > > Prepare: > > $invoice_line_amount = new NumberFormatter( 'fr_CH', > > NumberFormatter::DECIMAL ); > > $invoice_line_amount->setValue($res); > > > > View: > > echo $invoice_line_amount; > > > > We didn't purport to implement yet another MVC templating system here. We > wrote ICU wrapper. I was not clear, sorry. The goal is not to create a MVC but to allow easy and user friendly usage without having to use intermediate string variable or other custom objects. > > Locale specific: > > - Being able to parse, fetch and manage Locale IDs in a consistent and > > portable way would rock, the ISO3 related API is a must have prior > > 1.0. It can be used from day #1 to normalize locale IDs format. > > > > Could you elaborate? I think our functions understand locales in standard > formats, but maybe you mean something else. The idea is to have a way to get a code for a language, or to valid a given code, etc. Many applications actually duplicate this list internally, it would be very nice to be able to deal with the ICU lists (display, validation, listings, etc.). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
