Compound Dimension types in Java Units Library?

[chauser]

In working with arm torque calculations for our arm I'm really wishing I had a way to name compound dimensions such as Force and Torque instead of writing

Mult<Mass, <Velocity<Velocity<Distance>>>>

and

Mult<Mass, Mult<Distance, <Velocity<Velocity<Distance>>>>>

every time torque or force is needed as part of an even larger type.

Is there any hope that this can be done, either by the user or as part of the library? The limitation noted in the docs that Velocity<Distance> is different from and incompatible with Per<Distance, Time> makes me suspect that this may be hard to do without creating a lot of edge cases that would be infinitely confusing. But I thought it worth asking.

Also even if there isn't a way to do this, having Newton and PoundForce units with type Measure<Mult<Mass, <Velocity<Velocity<Distance>>>>> would be helpful for defining torque and spring constants.

This might be considered a feature request, but it feels more like discussion at this stage.

[calcmogul]

Since Java doesn't support typedefs, I'm not sure this can be done.

[chauser]

Yes I agree. So the only technically feasible approach might be to follow the model of Velocity. But I don't have a sense of how ugly that would get if such things proliferated. Force, however, seems particularly useful given its rather complicated expression in the fundamental units. I'm not willing to advocate going down that path at this point, but I did want to ask about it.

[SamCarlberg]

It was a design decision. There's a trade off between type safety, unit safety, and API shape. The Unit class doesn't need to have the self type as a generic type parameter, and it would actually be possible to inherit from other unit types (eg Velocity<D> extends Per<D, Time>) if we didn't have that constraint, but it allows us to enforce a type safe contract on subclasses ("a unit type U must provide a method that accepts a magnitude and returns a Measure", for instance). That would not be possible without knowing the self type; the best we could do is have the base Unit class return a raw type Measure with no type arguments, which is at odds with a type-safe unit system.

The poor ergonomics of highly nested generic types has been a recurring issue with the Java language ever since they added generics some twenty years ago. With no type aliasing mechanism, representing product types using generics can easy get to a point where the type you're declaring isn't really what it actually represents (like your example of torque - Mult<Mult<Mass, Velocity<Velocity<Distance>>, Time>, Distance> is just a horrendous way to represent Newton-meters). Unfortunately, the Java maintainers have been uninterested in alleviating the issue. So our alternatives are:

1. Define types in user code for Force and Torque, and accept poor interoperability with the wpilib units;
2. Overhaul the library to allow units to be subclassed and define more complex units while maintaining interoperability with the more basic units, most likely losing either type safety or user code flexibility; or
3. User code switches to a JVM language that provides type aliasing (eg Kotlin)