Skip to main content

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

  • From: Werner Keil <werner.keil@...>
  • To: "jcurrency_mail@..." <jcurrency_mail@...>, mhochschild@...
  • Subject: [JSR-354] Re: Comment on Public Review of jsr-354
  • Date: Thu, 21 Nov 2013 13:37:09 +0100

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


<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: 329.gif
Description: GIF image

Attachment: 347.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