Use Advanced Search to search the entire archive.
Convenience methods
- From: Werner Keil <
>
- To: "
" <
>
- Subject: Convenience methods
- Date: Thu, 30 Oct 2014 18:05:39 +0100
Otavio,
I already assigned
https://java.net/jira/browse/UNITSOFMEASUREMENT-67 to
you hoping you can help untangle the messy situation with those of()
methods in their current place.
The problem is BaseQuantity (
https://github.com/unitsofmeasurement/unit-ri/blob/master/src/main/java/tec/units/ri/quantity/BaseQuantity.java)
has no relation to concrete package local types like LongQuantity (
https://github.com/unitsofmeasurement/unit-ri/blob/master/src/main/java/tec/units/ri/quantity/LongQuantity.java)
or DoubleQuantity (
https://github.com/unitsofmeasurement/unit-ri/blob/master/src/main/java/tec/units/ri/quantity/DoubleQuantity.java
)
All examples in RI, but aside from different numeric types the rest is same
in SE port.
So this static convenience factory of() in BaseQuantity:
/** * Returns the scalar measure for the specified <code>long</code>
stated in * the specified unit. * * @param longValue * the measurement
value. * @param unit * the measurement unit. * @return the corresponding <
code>int</code> measure. */ public static <Q extends Quantity<Q>>
AbstractQuantity<Q> of( long longValue, Unit<Q> unit) { return new
*LongQuantity*<Q>(longValue, unit); }
makes no sense, as it returns a LongQuantity, similar for DoubleQuantity,
etc.
BaseQuantity has no knowledge of LongQuantity except they are in the same
package by coincidence.
If we insist of() only was defined on concrete classes, then I'm afraid,
the only solution would be to put them on the concrete final class like
LongQuantity and make that public.
Otherwise, see that JEP proposal, we should put all of() methods into the
abstract base class AbstractQuantity. Also see AbstractUnit.of().
Unlike numeric primitive Quantity subtypes, classes like ProductUnit are
final and public, thus if it needed an of() method so would all other
concrete Unit subtypes, but at least there it would be visible. It should
be done consistently for both Unit and Quantity types. Unless there is a
striking reason against it, the abstract base class sounds cleaner,
otherwise we must make the concrete classes visible.
Regards,
Werner
Convenience methods
|
Werner Keil |
10/30/2014 |