<i18n dev> java.util.Locale changes

[Christian Beikov]

Well it at least adds the possibility to use a Set directly as source. 
As stated before, this is just a remark because I thought one could also 
want to use a different Collection than a List. Using the Collection 
interface would also be enough.

Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 29.08.2013 10:24, schrieb Masayoshi Okutsu:
> I took a look at the implementation. The matcher code just iterates 
> the given priority list. isEmpty() is used, but it shouldn't be a 
> problem. As far as an Iterable gives an Iterator which consistently 
> iterates elements based on the priority or weight, the Iterable works.
>
> Use of Iterable does give more flexibility, but I'm not sure how much 
> it would add value to the API use. You can implement your own 
> Iterable, but would many developers implement an Iterable to give a 
> language priority list?
>
> Masayoshi
>
> On 2013/08/29 5:42, Alan Bateman wrote:
>> On 28/08/2013 14:25, Masayoshi Okutsu wrote:
>>> (adding core-libs-dev)
>>>
>>> Hi Christian,
>>>
>>> RFC 4647 defines The Language Priority List [1]. The use of 
>>> java.util.List would be a natural fit, which is the reason why List 
>>> is used. But use of Iterable does work (as API design). The 
>>> parameter name `priorityIterable' sounds a bit odd, though.
>>>
>>> Does use of Iterable add much value to the API? (Please note that 
>>> List is also used in Locale.LanguageRange.)
>>>
>> It depends on the usages but Iterable would be a bit more flexible. 
>> Does the locale matcher require to do anything except iterate over 
>> the elements? The return could be looked at it but it depends on the 
>> typical usage -- would the user of the API typically just iterate 
>> over the matched Locales?
>>
>> -Alan.
>