Hello all
Just a side note: me too I found the current JScience API a little bit too big,
and I'm actually somewhat happy that Google has reservations; I would like to
take this opportunity for simplifying and revisiting the API. But some of the
basic ideas could probably be preserved and better explained.
Bryce L Nordgren a écrit :
> The Jscience stuff seems to be hardcoded. Is there any particular reason a
> JSR should create a billion identifiers like "VOLT" and "METER"?
The API could work without them. They are only convenience constant providing
type safety in two ways:
- Avoid typos (e.g. Unit.valueOf("M") instead of Unit.valueOf("m") for metre)
- Provides the generic type (e.g. SI.METRE is declared as Unit<Length> while
Unit.valueOf("m") returns Unit<?>).
But this is just convenience. The internal is really working with arbitrary
combinaisons of base units raised to various powers, and we can build arbitrary
units with combinaisons of Unit.time(Unit), Unit.raise(int) etc. methods.
> Should they define all possible units, or just the basic ones?
This is the hard question. A possible approach was to define only the Unit
defined in the SI brochure (remind that they are convenience constants only;
the
API is in no way restricted to those units). But then come the Non-SI units
like
inch, days, etc. for which I'm not aware of any authority document.
> Worse, when they define Quantities, which quantities are important enough
> or common enough to predefine? For the compiler to check consistency, all
> Units and all Quantities must be declared as classes, which forces a
> situation where we must treat "Classes" as if they were "Objects".
Yes I fully agree. I was against Quantities interfaces in JSR-275 for exactly
this reason, but some other members pushed hard because they really want
compile-time safety. We could point out that those interfaces are not required
for javax.measure.units working and has no other purpose than compile-time
safety, so it is not a blocker if we dont define all quantities. But again the
hard question is which Quantities are common enough for deserving a declaration
in a standard API - I agree with you.
> But the worst failing of all: extension of the pre-existing units system is
> nearly impossible without writing code. Or if you prefer, it is impossible
> to write code which generically handles units.
This is not exact. A standard exists at least for SI units: the SI symbols,
which are well defined. So you can parse arbitrary units without writting any
code. Example:
Unit.valueOf("km/s")
will be translated into SI.KILO(SI.METER).divide(SI.SECOND). So you should be
able to combine units in arbitrary way in a String using "*", "/" operators and
raising to a power. The String parser should be quite powerful.
If you encounter a data
> file which expresses numbers in units of Canadian Dollars per hour, and if
> it comes with a full description in a standard format of the new Quantity
> (currency) and the new Units (Canadian Dollars), is it possible to ingest
> this file into a program which was not written with any knowledge of
> currency?
>
> No. You have to know ahead of time that "Currency" might be an item of
> concern. You have to write a class to "instantiate" currency by explicitly
> extending Quantity.
This is not necessary. You need to create a Currency interface extending
Quantity only if you want compile-time safety. Against those Quantities
interfaces serve no other purpose; the javax.measure.units package should work
just as well without them.
This is true that we need to defines the CAN currency units, but it could be
defined file to be parsed at runtime without compile-time knowledge. Nothing
more need to be defined, the javax.measure.units package should be able to
create the appropriate units by itself when parsing "CAN/h".
> In short, the JSR does not provide a "form" populated with a default set of
> values. It provides _the_ orthodox set of values. This is not the place
> of a JSR. Compile time checking is obtained at the cost of run-time
> extension and "class abuse".
No, it provides a form populated with a default set of values. The compile time
checking is totally optional.
> Check out:
> http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=unitsml
>
> Making something which implements OASIS's data model in the Java
> programming language would seem to be the way to go. This is how the units
> professionals choose to convey units. They don't include currency either,
> but note that they separate the framework from the set of default values
> such that one _can_ supply a currency definition to something which
> understands the framework.
Yes but I think they were a misunderstanding on javax.measure.units; it really
provides the same flexibility.
However maybe it was not clear, or badly explained. It would be surely worth to
uniformize with the Oasis model too. The problem is the usual one: volunter
time...
In summary:
- javax.measure.units is a pure "runtime check" framework. Quantities
interfaces and SI/NonSI convenience constants are totally useless for
its internal working, so users can really create new units at runtime
time without any compile-time knowledge.
- It is not possible to provides full compile-time safety in the Java
language as it stands today (note that it is possible in C++ at least
for SI units using "template" - Java generics do not have the same
level of flexibility).
- Real compile-time check would srequires Java language changes,
which is out of JSR-275 scope.
- Even if it is not possible to have full compile-time safety, some
JSR-275 members really wanted partial compile-time safety on the
basis that it would cover 80% of cases.
- I was against Quantities interfaces in JSR-275, because I would
prefer no compile-time safety at all rather than one with holes,
and leave the "compile-time safety" topic for later if we want
to do it right (with Java language change - not by me, I don't
have the required competence). I'm also worried that Quantity
interfaces would bring confusion because users could believe
that we need to define new interface in order to use new unit.
- The Google call for a simplier API is good new to me.
Martin
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
