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 12:24:46 +0100

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
 
 
Close
loading
Please Confirm
Close