Nebojša--
My votes, for whatever they may be worth...
1. For LocaleInfo I would like to include construction with plain string:
new LocaleInfo("de") vs more verbose new LocaleInfo({'languageID': 'de'})
One would be able to construct LocaleInfo like this:
LocaleInfo(); - default
LocaleInfo('sr');
LocaleInfo({}); - default
LocaleInfo({'languageID': 'sr', 'regionID': 'RU'); - and all variations
(missing regionID, missing languageID).
That seems appropriate to me.
2. Language matching - how detailed should we go in specifying language
matching process?
I think you should strive to define this precisely, unless it's going to put an
undue burden on some subset of implementers. But I think you want to find a
precedent and stay as close to it as possible. You want to avoid reinventing
wheels.
3. Derive methods were introduced to simplify creation of objects by tweaking
current settings. It works well when you override existing setting or when you
add new one. It's not so great when you want to remove a setting. For example:
The question is - do we keep derive methods? If so, do we care about this
case/my solution (since user has other ways to create the object)?
I'm going to have to take another look at the strawman (the current version
you're working from is posted somewhere, right?), but I think there's some
value here and that your suggestion of using "undefined" seems reasonable.
Just the same, it'd be better if the derive() method were smart enough to know
that specifying "dateType" isn't going to do anything unless it also un-defines
"skeleton". Otherwise, the developer has to remember that, or discover it the
hard way.
4. Should we rename LocaleInfo.collator()/numberFormat()/dateTimeFormat() into
LocaleInfo.createCollator()...? It makes it clear we are creating new object.
Yes.
5. I think that calendar settings for DateTimeFormat doesn't bring much value
and makes implementation more complex. Overriding default calendar is rare
operation, and can be easily done with -u-ca extension - one just needs to
create new locale.
Probably better to just use the locale, unless that's going to cause an undue
burden for implementers. (From my perspective, I'm trying to implement this on
top of ICU, and would prefer whatever forces me to write the least amount of
code above and beyond what ICU provides.)
6. I would rename dateSkeleton into skeleton in DateTimeFormat settings.
I don't really care.
As I said, for whatever it's worth...
--Rich Gillam
Lab126
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
