Use Advanced Search to search the entire archive.
Re: Proposal
- From: Jean-Marie Dautelle <
>
- To:
- Subject: Re: Proposal
- Date: Sun, 2 Nov 2014 13:15:43 +0100
Errata:
public void wait(Time delay) {
long microseconds = delay.to(MICRO(SECOND)).value().longValue();
Thread.wait(microseconds);
}
On Sun, Nov 2, 2014 at 1:11 PM, Jean-Marie Dautelle
<
>
wrote:
>
> I also assume, you don't want to eliminate the to(Quantity) method from
>
Quantity, do you?
>
>
Not necessarily. A quantity may be stated in any compatible unit.
>
>
public void wait(Time delay) {
>
long microseconds = delay.to(MICRO(SECOND)).longValue();
>
Thread.wait(microseconds);
>
}
>
>
> WDYT?
>
>
Fully agree, the API should have only interfaces!
>
>
>
On Sun, Nov 2, 2014 at 12:50 PM, Werner Keil
>
<
>
>
wrote:
>
>
> I also assume, you don't want to eliminate the to(Quantity) method from
>
> Quantity, do you?
>
>
>
> Fowler proposes exactly that signature, though he also leaves it open to
>
> create a separate Converter element, see JSR 354 simply because you need to
>
> know a lot more for currency conversion like time, date, type (cash, card,
>
> bond, ...) of monetary amount, etc.
>
> So far we had a fairly simple conversion here, nevertheless typesafe
>
> thanks to generics.
>
>
>
> If only Quantity existed, then like in other cases MeasurementConverter
>
> (defining the to()) and ValueSupplier would only serve one interface, hence
>
> could logically be merged into Quantity.
>
>
>
> If a common understanding is (unlike OpenXC where non-numeric quantities
>
> are indeed also treated typesafe via a "Unit", but it got no operations on
>
> the other hand) a multitude or non-numeric quantity would not even have a
>
> unit, then the current Measurement becomes redundant, as the only purpose
>
> would be to make these multitudes type-safe, too.
>
>
>
> In the interest of an ultra-slim approach for smallest devices (that need
>
> just a single Unit and Quantity, either from our pre-defined SI stack or
>
> something completely different)
>
> could we move the now "orphaned" QuantityFactory and SystemOfUnits into
>
> SPI (as they have no external dependencies to them in mandatory base-types)
>
> and push UnitConverter up into the root package instead?
>
>
>
> This makes us or users more flexible regarding optionality all optional
>
> packages depend only on the base elements, not even on each other[?]
>
> And only the root package "javax.measure" contains mandatory core
>
> elements.
>
>
>
> WDYT?
>
>
>
> On Sun, Nov 2, 2014 at 12:40 PM, Jean-Marie Dautelle
>
> <
>
>
> wrote:
>
>
>
>> > Do I'm understanding right?
>
>>
>
>> Yes 100 %
>
>>
>
>> On Sun, Nov 2, 2014 at 12:24 PM, Martin Desruisseaux <
>
>>
>
>
>> wrote:
>
>>
>
>>> Hello Jean-Marie
>
>>>
>
>>> To summarize, you are suggesting three things:
>
>>>
>
>>>
>
>>> 1. Remove the Measurement interface in order to avoid the
>
>>> conceptual problem with hierarchy.
>
>>> 2. Define the Quantity interface as a quantitative measurement
>
>>> (since it contains a value and a unit).
>
>>> 3. Overload the multiply and divide methods for type safety.
>
>>>
>
>>>
>
>>> Do I'm understanding right?
>
>>>
>
>>> Martin
>
>>>
>
>>>
>
>>
>
>>
>
>> --
>
>> It is not the strongest of the species that survives, nor the most
>
>> intelligent. It is the one that is most adaptable to change. - Darwin's
>
>> Origin of Species (digest)
>
>>
>
>
>
>
>
>
>
--
>
It is not the strongest of the species that survives, nor the most
>
intelligent. It is the one that is most adaptable to change. - Darwin's
>
Origin of Species (digest)
>
--
It is not the strongest of the species that survives, nor the most
intelligent. It is the one that is most adaptable to change. - Darwin's
Origin of Species (digest)
Attachment:
347.gif
Description: GIF image