Use Advanced Search to search the entire archive.
Re: Remove "generic" multiply/divide operations from Quantity
- From: Werner Keil <
>
- To:
- Subject: Re: Remove "generic" multiply/divide operations from Quantity
- Date: Sat, 18 Oct 2014 13:08:49 +0200
I asked them practical questions close to the domain, not things like
"reification";-)
If they'd accept to cast in their own code or if the worst came to the
worst even preferred arithmetics in their own implementation.
The challenge of e.g. trying to filter all units by quantity, not dimension
is something I looked into a long time ago. I believe I had a Reflection
based solution but if it was ever in a repo, it was lost when JSR-275 was
purged from java.net. So nothing new to learn here, just having to live
with Java being sublime to e.g. .NET in a few aspects;-)
Nobody will really solve a "generic" way of enforcing say "10 km/h" is
correct, but "10 kg/h" is not. That will almost always be a runtime
decision. UCUM allows that kind of parsing and in theory the XML could
dynamically change or update;-)
Trying to harness a Java line of code, the mere experiments by JSR 308
Checker annotations could help.
It needs to be written out for every possible combination of units
imaginable, meaning that Arithmetic Rule set will likely never be possible
to standardize to say meet the needs of Eclipse or other IoT.
Take BMI, CO2 footprint or Heating requirement of a home just as 3 out of
3k to 30k other formulas;-)
Am 18.10.2014 12:41 schrieb "Martin Desruisseaux" <
>:
>
Le 18/10/14 04:40, Werner Keil a écrit :
>
>
I asked the guys from the Eclipse IoT project how they feel about having
>
to cast based on the current wildcard, if they have a strong opinion, we'll
>
see.
>
>
Werner, can we see the question that you asked to them? I would like to
>
check if you finally understood the problem.
>
>
While asType() causes fewer problems now under SE 8, seems, it never
>
preserved the target type either[?]
>
>
What do you mean? The JScience 5 code that you pasted shows that
>
asType(Class) does its job, which is to throw a ClassCastException at
>
runtime if the type is wrong. The asType(Class) purpose has never been to
>
provide compile-time safety.
>
>
Running a ReflectionDemo to get the actual generic type Q (this would
>
only work with a trick of storing it in the constructor, but that required
>
concrete classes for every case, no <?> or so)
>
>
What are you trying to do with this ReflectionDemo? It has nothing to do
>
with what I suggested (java.lang.reflect.Proxy as a way to provide
>
Quantity implementations for all subtypes).
>
>
Naively speaking, one could have expected anotherUnit to have an actual
>
type argument of Volume, but it it Q instead.
>
>
So you are just starting to discover the meaning of "type erasure", at
>
last.
>
>
Is that, how asType() should work?
>
>
No reflection. Only something like a Map<Class<Quantity<?>>, Dimension>
>
somewhere. Or a Map<Class<Quantity<?>>, Unit<?>> where the unit is the
>
system unit (not all possible units of that quantity - only the system
>
unit). Unit compatible with that one are considered valid.
>
>
Anyway, this is an implementation question, while UNITSOFMEASUREMENT-62 is
>
a Java language problem.
>
>
>
Let's see, what the Eclipse stakeholders say, I hope the question did
>
not scare them?[?]
>
>
It depends how you explained the problem to them, which I would like to
>
see...
>
>
Martin
>
>
Attachment:
329.gif
Description: GIF image
Attachment:
35F.gif
Description: GIF image