Skip to main content

[JSR-354] Re: Spec Updated

  • From: Werner Keil <werner.keil@...>
  • To: "jcurrency_mail@..." <jcurrency_mail@...>
  • Subject: [JSR-354] Re: Spec Updated
  • Date: Mon, 14 Oct 2013 12:42:32 +0200

Anatole,

I assume you refer to
http://download.java.net/jdk8/docs/api/java/time/temporal/TemporalQuery.html
well,
IMHO we're still missing a MonetaryField.
That's precisely the element that allows something that would be
>The MonetaryField interface provides another mechanism for querying
monetary amounts. That interface is limited to returning a long. By
contrast, queries can return any type.
I am not sure, if the query (much more an enterprise feature from what we
discussed) makes sense on a JDK level, but if Java 8 throws it into the
already monolithic giant pot for Time, we might as well do so for
Money/Currency[?]

See Japan or other examples with multiple submultiples of a whole amount,
or Google's recommendation, I think the current "Major/Minor" approach is
not sufficient for an interface that should also match the general idea
behind TemporalAmount.

Cheers,
Werner

 Werner Keil | JCP Executive Committee Member | Eclipse UOMo Lead, Babel
Language Champion | Java Godfather

Twitter @wernerkeil | @JSR354 | #EclipseUOMo | #Java_Social | #DevOps
Skype werner.keil | Google+ gplus.to/wernerkeil

* JMaghreb 2.0: Nov 7-8 2013, Casablanca, Morocco. Werner Keil, JCP EC
Member, JSR 354 EG Member will present "Java Social", "JSR 354"


On Mon, Oct 14, 2013 at 8:25 AM, Anatole Tresch <atsticks@...> wrote:

> Hi Werner/all
>
> we see already use cases for queries using functional style, e.g. counting
> the number of amounts that exceeds some amount, or more generally
> implementing predicates for queries or statistical calculations. So I
> clearly agree with Stephen on the requirement to have an extension point
> that is not required to return monetary amounts.
>
> I think it is a very important point to stick to the naming of 310 here.
> So I do not see any reasons to change anything here.
>
> Cheers,
> Anatole
>
>
>
> 2013/10/14 Werner Keil <werner.keil@...>
>
>> Adjuster somewhat similar to Rounding feels OK, it's like turning a
>> wheel. The query feels a bit abstract and JavaMoney already contains
>> clearer functional interfaces meant for Lambda, too;-)
>>
>> Without a strong use case I'm not sure, if query makes sense.
>> Will check with other JSRs, there are at least 2 others defining a
>> "query" mechanism.
>>
>> Werner
>> Am 14.10.2013 00:03 schrieb "Stephen Colebourne" <scolebourne@...>:
>>
>>> Adjuster and Query are a very open variation of the strategy design
>>> pattern. They allow behaviour to be encapsulated outside of the main
>>> money class. They are named and behave exactly as per JSR-310, which
>>> users of the API will appreciate. They also fit well into a
>>> functional/lambda world.
>>>
>>> Stephen
>>>
>>>
>>>
>>> On 13 October 2013 18:13, Werner Keil <werner.keil@...> wrote:
>>> >
>>> > So far MonetaryQuery.queryFrom() is used 3 times in the RI.
>>> >
>>> >
>>> > The JavaDoc
>>> >  /** * Queries this monetary amount for a value. * <p> * This queries
>>> this amount using the specified query strategy object. * <p> *
>>> Implementations must ensure that no observable state is altered when this 
>>> *
>>> read-only method is invoked. * * @param <R> * the type of the result *
>>> @param adjuster * the query to invoke, not null * @return the query 
>>> result,
>>> null may be returned (defined by the query) */
>>> >
>>> > is a bit buggy to start with. "adjuster" should be called query, and
>>> the whole notion of query(Query) seems a little odd.
>>> > The text should be clarified, "value" is meaningless, especially since
>>> you need to pass a query and all that query does so far is to route to its
>>> internal (less conveniently named) proxy method. I think we should try to
>>> untangle that, it feels a bit redundant.
>>> >
>>> > Werner
>>> >
>>> > On Sun, Oct 13, 2013 at 6:53 PM, Werner Keil <werner.keil@...>
>>> wrote:
>>> >>
>>> >> Anatole/all,
>>> >>
>>> >> I changed a few links to the Git repositories already as they were
>>> outdated.
>>> >>
>>> >> Just rephrased a method to match the actual code, but the JavaDoc in
>>> MonetaryQuery leaves more questions than we would like to see unanswered.
>>> >>
>>> >>
>>> >>  * It is recommended to use the second approach, {@code
>>> query(MonetaryQuery)},
>>> >>  * as it is a lot clearer to read in code.
>>> >>
>>> >>
>>> >> If it is recommended to use a totally different method, then  can't
>>> we just call it query() and use that interface, or let's drop 
>>> MonetaryQuery
>>> from the spec to avoid lose ends?
>>> >>
>>> >> These "we specify A,  but you should use B because A has a stupid
>>> name" makes no sense and confuses people.
>>> >>
>>> >> There's already enough ambiguity e.g. in the current JSPA or Process
>>> document, some of us in the EC hope to resolve, so couldn't we try to keep
>>> that out of specs please
>>> >>
>>> >> Cheers,
>>> >> Werner
>>> >>
>>> >>
>>> >>
>>> >> On Sun, Oct 13, 2013 at 10:32 AM, Simon Martinelli <
>>> simon.martinelli@...> wrote:
>>> >>>
>>> >>> Hi Anatole,
>>> >>>
>>> >>> I was 3 weeks in vacation but now I am back and read the spec.
>>> >>> Unfortunately I am not able to add comments. Can you please give me
>>> the necessary authorization?
>>> >>>
>>> >>> Thanks,
>>> >>> Simon
>>> >>>
>>> >>>
>>> >>> On Sat, Oct 12, 2013 at 9:08 PM, Anatole Tresch <atsticks@...>
>>> wrote:
>>> >>>>
>>> >>>> Dear all
>>> >>>>
>>> >>>> I have updated the spec and accommodated the latest input, mainly
>>> from Stephen. I think we have a small, comprehensive and very elegant 
>>> spec,
>>> so thanks to all (especially Stephen) for your time and contributions.
>>> >>>> I have left some comments, so you may see easily, where there might
>>> be points to be discussed.
>>> >>>>
>>> >>>> So please revise the spec once more, and add your comments directly
>>> into the document (as Google Doc comment). If you feel OK, with the 
>>> current
>>> state to progress, please add a comment at the end of the document, so I
>>> know we have now an agreement on the current document and I see who 
>>> finally
>>> has read it!
>>> >>>>
>>> >>>> Here is the link:
>>> >>>>
>>> https://docs.google.com/document/d/1FfihURoCYrbkDcSf1WXM6fHoU3d3tKooMnZLCpmpyV8/edit#heading=h.5wnzm49wl111
>>> >>>>
>>> >>>> I would be glad, if we can do that within the next 2-3 days, so we
>>> can then finally publish our Public Review. I will check now, if the API
>>> JavaDoc requirements are aligned with the current spec.
>>> >>>>
>>> >>>> Have a nice weekend!
>>> >>>> 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
>>> >>>> Mobile  +41-76 344 62 79
>>> >>>
>>> >>>
>>> >>
>>> >
>>>
>>
>
>
> --
> *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
> Mobile  +41-76 344 62 79*
>

Attachment: 35C.gif
Description: GIF image



[JSR-354] Spec Updated

Anatole Tresch 10/12/2013

[JSR-354] Re: Spec Updated

Simon Martinelli 10/13/2013

[JSR-354] Re: Spec Updated

Werner Keil 10/13/2013

[JSR-354] Re: Spec Updated

Werner Keil 10/13/2013

[JSR-354] Re: Spec Updated

Anatole Tresch 10/13/2013

[JSR-354] Re: Spec Updated

Stephen Colebourne 10/13/2013

[JSR-354] Re: Spec Updated

Werner Keil 10/13/2013

[JSR-354] Re: Spec Updated

Anatole Tresch 10/14/2013

[JSR-354] Re: Spec Updated

Werner Keil 10/14/2013

[JSR-354] Re: Spec Updated

Anatole Tresch 10/14/2013

[JSR-354] Re: Spec Updated

Werner Keil 10/14/2013

[JSR-354] Re: Spec Updated

Stephen Colebourne 10/14/2013

[JSR-354] Re: Spec Updated

Werner Keil 10/14/2013

[JSR-354] Re: Spec Updated

Anatole Tresch 10/15/2013

[JSR-354] Re: Spec Updated

Werner Keil 10/15/2013

[JSR-354] Re: Spec Updated

Anatole Tresch 10/15/2013

[JSR-354] Re: Spec Updated

Mark Davis ☕ 10/15/2013

[JSR-354] Re: Spec Updated

Anatole Tresch 10/13/2013
 
 
Close
loading
Please Confirm
Close