Skip to main content

[JSR-354] Re: Comment on Public Review of jsr-354

  • From: Stephen Colebourne <scolebourne@...>
  • To: jcurrency_mail@...
  • Subject: [JSR-354] Re: Comment on Public Review of jsr-354
  • Date: Thu, 21 Nov 2013 16:03:42 +0000

The API already supports querying the value.

BigDecimal value = money.query(BigDecimalQuery.INSTANCE)

Its a safe version of the method you suggested.

Stephen




On 21 November 2013 15:46, Tresch, Anatole (KGVA 28) <
anatole.tresch@...> wrote:

>  Hi all,
>
>
>
> If we would introduce a method to access the numeric value, I would
> propose something like:
>
>
>
> public <T> getNumber(Class<T> type);
>
>
>
> We then also might also add something like:
>
>
>
> public Collection<Class> getSupportedNumberTypes();
>
>
>
> This would prevent users from “accidentally” using *Number* and also
> leaves room for future extensions. But I would NOT want to return 
> Numberexplicitly here. We could then require to support
> BigDecimal on SE, which also can easily be tested by the TCK.
>
>
>
> Cheers,
>
> Anatole
>
>
>
> Anatole Tresch
>
> *CREDIT SUISSE AG*
>
> Information Technology | Java Core Framework & Support
>
> Spec Lead JSR 354 Money & Currency
>
> 8070 Zürich | Switzerland
>
> Phone +41 44 334 03 89
>
> anatole.tresch@... | www.credit-suisse.com
>
>
>
> *From:* Werner Keil [mailto:werner.keil@...]
> *Sent:* Thursday, November 21, 2013 13:37
> *To:* jcurrency_mail@...; mhochschild@...
> *Subject:* [JSR-354] Re: Comment on Public Review of jsr-354
>
>
>
> Actually you don't need to wait for JSR 308 to handle ReadOnly behavior,
> take JavaFX again:
> http://download.java.net/jdk8/jfxdocs/javafx/beans/property/ReadOnlyProperty.html
>
>
>
> The "mother" of all value types there is:
> http://download.java.net/jdk8/jfxdocs/javafx/beans/value/ObservableValue.html
>
>
>
> IMHO a generics based pattern like
>
> T 
> <http://download.java.net/jdk8/jfxdocs/javafx/beans/value/ObservableValue.html>
>  getValue()
>
>  Returns the current value of this ObservableValue
>
> *Returns:*
>
> The current value
>
> is precisely what MonetaryAmount is missing.
>
>
>
> Google while still in the EC made a review comment during the PDR of JSR
> 275 on an aspect of the API back then (Unit-API has addressed most of these
> and more) claiming, that aspect sounded like the language of a "19th
> Century French Nobleman", of course the time when much of the SI unit
> system was defined...
>
>
>
> getAmountFractionDenominator() or getAmountFractionNumerator() I'm sorry
> to say sound exactly the same. You may find Scrooge in "A Christmas Carol"
> and writers from the same "epoch" use that when pinching their pennies, but
> no sane and real life person today outside a high school or university math
> class will use such terms.
>
>
>
> T getValue() with MonetaryAmount<T extends Number> if you want allowing
> each implementing like Moneta Money to chose the right representation would
> be far more understandable.
>
> JavaFX 8 does that ever since version 2:
>
> public interface *ObservableNumberValue*
>
> extends ObservableValue 
> <http://download.java.net/jdk8/jfxdocs/javafx/beans/value/ObservableValue.html><java.lang.Number>
>
>  A common interface of all sub-interfaces of 
> ObservableValue<http://download.java.net/jdk8/jfxdocs/javafx/beans/value/ObservableValue.html>
>  that
> wrap a number.
>
>
>
> Why can't other APIs that hope to become part of the JDK one day, too
> learn from that?
>
>
>
> Werner
>
>
>
> On Thu, Nov 21, 2013 at 12:24 PM, Werner Keil <werner.keil@...>
> wrote:
>
>
>
> On Thu, Nov 21, 2013 at 11:53 AM, Stephen Colebourne <scolebourne@...>
> wrote:
>
> On 21 November 2013 09:29, Meno Hochschild <mhochschild@...> wrote:
> > Of course there is a solution in form of properly applied generics. We
> know
> > very well that JSR-310 project team leaders do all to avoid generics
> because
> > they consider it as "messy". But this is the language feature Java
> offers as
> > solution. And on concrete application level the solution is not at all
> > messy, but very helpful and readable.
>
> Not quite so. In JSR-310 I found no way to get generics to actually
> work. The problem which 310 tackles involves many more interacting
> interfaces, and the increased friction between the types nullifies the
> benefits of generics. (For example, a 310 adjuster might only work on
> a date but be applied to a date-time)
>
>
>
>
>
> Most likely due to a lack of experts like Jean-Marie, Martin and others
> who helped make this work well between JSR 275 and Unit-API. Or those
> working on JavaFX
>
>
>
>
> > A MonetaryAdjuster must always be written for a special type. In the
> current
> > state of JSR 354 instanceof-checks and type-casts cannot be avoided using
> > the present method signature. This is in my opinion a heavy regression
> back
> > to the time before JSR 14 was introduced in Java 5. Astonishing when you
> > plan your JSR for even Java 9.
>
> The intention here was to be slightly different to 310.
>
> An implementation of an adjuster would be permitted to return any type
> of MonetaryAmount (NB. the Javadic may not have ended up refecting
> this). Thus the adjuster might be:
>
> public MonetaryAmount adjustInto(MonetaryAmount a) {
>   return MyMoneyClass.from(a).doMyAdjustment()
> }
>
> and the caller would be
>
> public FooMoney with(MonetaryAdjuster adj) {
>   return FooMoney.from(adj.adjustInto(this));
> }
>
> As such, the lack of generics is deliberate.
>
>
> On the MonetaryAmount signature, what is really needed is the "self
> type", a special type that declares itself as the type of the current
> type. If this existed and had the syntax <this>, then the
> MonetaryAmount interface would be defined as:
>
> public <this> adjustInto(MonetaryAmount amount);
>
> The self type is a well known language concept. I've found its
> omission from Java particularly affects immutable classes, like we
> have here. http://blog.joda.org/2007/08/java-7-self-types_1953.html
>
>
> A more interesting question is whether MonetaryAmount should be
> read-only, which would sidestep the debate. My primary concern is
> defining an interface that allows a full formatter/parser to be built,
> similar to 310's DateTimeFormatterBuilder. Before the API is locked
> down, such a full formatter (that uses the API but isn't part of the
> API) needs to be fully worked through (I know that work has already
> been done on this). Until I have a good feel for the parser, its hard
> to have a good sense of whether the adjuster is needed there (I
> suspect it isn't).
>
>
>
> For these I'm afraid you'll have to "swallow" JSR 308 checkers some day
>
> I'm only following them on the sidelines, e.g. to see if there are
> synergies from its (again only SE so like 310 that disqualifies them from a
> broad enough use in devices we hear are all going to run Java within a few
> months, years at most) checkers, especially the ones around Units and
> Quantities, but there are all sorts of annotations, see the OpenJDK page
> you must have brushed a few times, too:
> http://openjdk.java.net/projects/type-annotations/
>
>
>
> Stephen
>
>
>
>
>
> Werner
>
>
>

Attachment: image002.gif
Description: GIF image

Attachment: image001.gif
Description: GIF image



[JSR-354] Comment on Public Review of jsr-354

Meno Hochschild 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Stephen Colebourne 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Werner Keil 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Werner Keil 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Tresch, Anatole (KGVA 28) 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Werner Keil 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Stephen Colebourne 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Tresch, Anatole (KGVA 28) 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Werner Keil 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Tresch, Anatole (KGVA 28) 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Werner Keil 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Tresch, Anatole (KGVA 28) 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Werner Keil 11/21/2013

[JSR-354] Re: Comment on Public Review of jsr-354

Werner Keil 11/21/2013
 
 
Close
loading
Please Confirm
Close