[loc-en-dev] getLocaleKeywordKeys/Value

[Doug Felt]

Yesterday during the conference call there was an objection raised to
providing LDML-extension-specific API on Locale.

The argument against, as I understand it, is that in the future there might
be other extensions, and Locale might need to support them.  Special casing
support for the LDML extension doesn't look clean.

The argument for, as I understand it, is that LDML extensions are in process
and will be defined before JDK7 is released, and that these are important
for making use of LDML data in the JDK.

One suggested compromise was to provide an LDML accessor object so that the
LDML-specific API resided on a different class.  I think this is not going
to work out.

It seems to me that we would require an LDML-specific builder as well as an
accessor.  Locale.Builder currently understands both  BCP47 and LDML syntax
constraints, so knowledge of the LDML API and constraints would have to be
migrated off it.   An LDML builder that holds the LDML-specific API is
mutable, but ideally the LDML accessor is not (it represents the LDML
extension on a Locale in API form, and semantically this is cleaner if it is
also immutable, like Locale), so this means two classes per extension, an
accessor and a builder (just like there is both a Locale and a
Locale.Builder).

Builder is currently strict, and I don't think we want to make it strict
only for BCP47 and non-strict for extensions.  So we'd need to provide API
on Builder that allows for imposition of those additional extension
constraints from outside.

Builder currently provides a public setExtension(String) API.  Access to
this API without going through an extension builder means it is possible to
create language tags that are well-formed from the point of view of BCP47
but that contain ill-formed LDML (or other extension) tags.  Thus this API
cannot take a String unless it already knows how to syntax check the
extension.  This API could be changed to take an ExtensionBuilder instead of
a String, but then the same problem occurs with setLanguageTag.  Since this
can take strings containing multiple extensions we'd either need to
parameterize the call with extension builders or parameterize the Builder
itself with extension syntax checkers.

A user-implementable API for extension builders means it is also possible to
create different builders for the same extension with conflicting syntax
constraints.

So I think we'd probably want to implement extension support in the JDK in a
non-extensible way.  Once we do that, it's baked in anyway, so the question
is whether we put the API in Locale and Locale.Builder, or on some other
objects.  Putting it on other objects makes use of the APIs much more
cumbersome, especially as this is the default use.  Putting the API on
Locale and Locale.Builder doesn't prelude adding other API in the future and
makes the use of Locale and the Builder significantly simpler.

Doug
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/locale-enhancement-dev/attachments/20090311/461808d5/attachment.html