Built in derived units

[mongoose13]

Some derived units probably make sense to support out of the box.

Examples:

• Newton (N)
• Pascal (Pa)
• joule (j)
• Watt (W)
• Volt (V)
• ...

Ideally, they would not only have conversions among themselves (e.g. Newtons convert to dynes), but they could also be broken down into their component parts to facilitate measurement creation (e.g. create a Newton measurement from mass and acceleration).

[mongoose13]

Just putting a brain dump here on one possibility.

I'll shorten UnitPosition subclasses with just N for numerators and D for denominators to make this more readable

1. Remove the Measurement class, and instead have each subclass implement all of the methods
   1. This is done via code generation, so it's not so bad
   2. The goal is to allow specific measurement classes to be constructed via each method, i.e. DistanceMeasurement instead of Measurement<Distance> from the construct() method, and by extension things like addition and sum.
2. Create classes for each degree of derived measurement (currently up to 3), e.g. DerivedMeasurement3.
   1. These should have a DerivedUnitX as their defaultUnit type.
   2. This allows normal conversions by accepting a DerivedUnitX instead of the standard unit type, e.g. speed.butAs(knots) and speed.butAs(miles.per.hour) would both work, via DerivedMeasurement2 butAs(DerivedUnit2<N<Distance>, D<Time>, Distance, Time>) (coded as DerivedUnit2<P1, P2, D1, D2>)
   3. These need to define per and by by "flattening" their components, e.g. meters.per.second.per.second should result in a DerivedMeasurement3 and not DerivedMeasurement2<DerivedMeasurement2<Distance, Time>, Time>
3. Define an additional parameter in the DimensionConfig annotation to allow a configured dimension to have a degree higher than 1 (maybe String? degrees as a comma separated list, if null then degree is 1, otherwise values might look like UnitNumerator<Distance>,UnitDenominator<Time>). 1. This would be used to define the conversion methods (as and butAs) on the generated derived measurement class.
4. Define an additional parameter in the UnitConfig annotation to allow a unit to exist but not be visible in extension methods, etc. (probably something like bool isVisible = true)
   1. This allows a dimension like "speed" to define its SI unit as "meters per second" without exposing metersPerSecond as an option for extensions on num and builders.

With all of this, we can define a class (using the builders) for, say, Acceleration, that:

• defines its own units (e.g. "Gal")
• accepts conversions to or from handmade equivalent derived units in a type-safe way (e.g. "meters.per.second.per.second")
• automatically accepts special conversions (e.g. "knots.per.second" if "knots" is a Speed unit Distance/Time that "flattens" out to [N<Distance>, D<Time>, D<Time>])

[mongoose13]

Status update:
A good portion of the Measurement class is ported out. I've set up Measurement classes for derived units up to 3 dimensions (by hand) and they seem to work for a few of my "test" units, e.g. Speed. I have a code generator for simple derived units that Speed uses.

Pending:

• Code generator for Measurement classes of any dimension number
• Code generator for Unit classes of any dimension number
• Code generator for custom derived units with 3+ dimensions