Skip to main content

[JSR-354] Re: Region API/SPI

  • From: Stephen Colebourne <scolebourne@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: Region API/SPI
  • Date: Mon, 15 Jul 2013 07:48:30 +0100

Providing a Region API is quite a major job. It would need to be done
in association with changing Locale, as Locale is the primary class
for accessing a region today. In addition, the design of Locale would
encourage a separate Language object to represent the language part of
the locale.

In addition, creating region hierarchies will have a tendency to be
quite business specific. Different organizations will get that data
and structure it in different ways. Credit Suisse's view and Expedia's
view are probably different.

This, and amount type, feel more like trying to create a general
"business utilities" library, rather than a money API.

On the specific design, why "GER"? Locale defines "DE".
Why Regions.get() when Java is moving to Regions.of()?
Why RegionNode and not Region?

Stephen



On 14 July 2013 23:44, Anatole Tresch <atsticks@...> wrote:
> Dear all
>
> yet another topic is the Regions API. I wold like to do another proposal to
> simplify/separate concerns:
> https://github.com/atsticks/javamoney/tree/master/money-api/ext/src/main/java/javax/money/ext
> https://github.com/atsticks/javamoney/tree/master/money-api/ext/src/main/java/javax/money/ext/spi
>
>
> Hereby the keypoints are:
>
> A Region is just an interface with
> - a RegionType (as before)
> - a textual code (required)
> - an (optional) numeric ID
> And yes, this is very similar to what we have in the area of currrencies.
> Similar to currencies (but without the regional relation) I can access
> RegionValidty instances.
> Additionally I can access the (possibly) different RegionNode as region
> forest, or access a RegionNode  by its top level region identifiers (type,
> code). The RegionNode   similar to the previously modeled Region, has a
> parent and children and allows for tree navigation.
>
> This makes the API quite simply, e.g.
>
> Region ger = Regions.get(RegionType.COUNTRY, "GER"); // Germany
> RegionNode reg = Regions.getRegionNode(ger);
> Collection<RegionNode> children = reg.getChildren();
>
> RegionNode reg2 = Regions.get(RegionType.COUNTRY, "GER"); // Germany
> RegionNode reg3 = Regions.get("WOLRD/EUROPE/COUNTRIES/ISO/GER");
>                      // Germany by path
>
> On the spi side this has some advantages:
>
> Spi implementation for region definition, region validity and region tree
> structure can be easily separated.
> Access to regfions/region nodes is still simple.
> Region tree is highly adaptable and easy to extend.
>
> So have a look at this and write down your feedback.
>
>
> Have a good night (or morning...).
> - Anatole
>
> --
> Anatole Tresch
> Java Lead Engineer, JSR Spec Lead
> Gl√§rnischweg 10
> CH - 8620 Wetzikon
>
> Switzerland, Europe Zurich, GMT+1
> Twitter:  @atsticks
> Blogs: http://javaremarkables.blogspot.ch/
> Google: atsticks
> Phone   +41-44 334 40 87
> Mobile  +41-76 344 62 79


[JSR-354] Region API/SPI

Anatole Tresch 07/14/2013

[JSR-354] Re: Region API/SPI

Stephen Colebourne 07/15/2013

[JSR-354] Re: Region API/SPI

Tresch Anatole (KFSC 225) 07/15/2013

[JSR-354] Re: Region API/SPI

Werner Keil 07/15/2013
 
 
Close
loading
Please Confirm
Close