On Sat, Jul 13, 2013 at 1:05 PM, André Bargull <andre.bargull at udo.edu>wrote:

>  ...
> Only exposing CanonicalizeLanguageTag does not seem useful to me without
> having access to IsStructurallyValidLanguageTag. Most likely a combined
> IsStructurallyValidLanguageTag + CanonicalizeLanguageTag function is
> necessary/wanted for most use cases.
>

Hmm.  I'm not sure I'd agree it's necessary.
 IsStructurallyValidLanguageTag makes sense as an abstract function because
you need to throw accordingly when an invalid tag is passed to the
constructors or methods.  However, it's still the developer's
responsibility to make sure their tags are valid during the development
process.  Canonicalisation would still throw an error if the tag is invalid.


>  I don't see why you'd need to change CanonicalizeLocaleList at all. Just
> let it return the internal list as-is, and then define
> `Intl.canonicalizeLocaleList` like so:
>

Lists are internal, they aren't part of the ECMAScript language.  It makes
no sense to return an internal list to ECMAScript code unless you intend to
go the whole hog and specify them with a constructor/prototype.


> It also needs to be considered whether the duplicate removal in
> CanonicalizeLocaleList creates any issues for users of a potential
> `Intl.canonicalizeLocaleList` or `Intl.canonicalizeTags` function.
>

Perhaps.  Are there any cases you think of where removing duplicates would
be a problem?

Andy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130713/af66e3ec/attachment.html>

On Sat, Jul 13, 2013 at 1:05 PM, André Bargull <andre.bargull at udo.edu> wrote:

>  ...
> Only exposing CanonicalizeLanguageTag does not seem useful to me without
> having access to IsStructurallyValidLanguageTag. Most likely a combined
> IsStructurallyValidLanguageTag + CanonicalizeLanguageTag function is
> necessary/wanted for most use cases.
>

Hmm.  I'm not sure I'd agree it's necessary.
 IsStructurallyValidLanguageTag makes sense as an abstract function because
you need to throw accordingly when an invalid tag is passed to the
constructors or methods.  However, it's still the developer's
responsibility to make sure their tags are valid during the development
process.  Canonicalisation would still throw an error if the tag is invalid.


>  I don't see why you'd need to change CanonicalizeLocaleList at all. Just
> let it return the internal list as-is, and then define
> `Intl.canonicalizeLocaleList` like so:
>

Lists are internal, they aren't part of the ECMAScript language.  It makes
no sense to return an internal list to ECMAScript code unless you intend to
go the whole hog and specify them with a constructor/prototype.


> It also needs to be considered whether the duplicate removal in
> CanonicalizeLocaleList creates any issues for users of a potential
> `Intl.canonicalizeLocaleList` or `Intl.canonicalizeTags` function.
>

Perhaps.  Are there any cases you think of where removing duplicates would
be a problem?