Java "Unit" classes

[ghost]

Is your feature request related to a problem? Please describe.
The lack of sane units in Java can cause hard-to-identify problems where wrong units are passed into the wrong place. These are sneaky and hard to debug.

Describe the solution you'd like
Sane unit classes that represent some kind of physical value, for example, a Distance class for meters, feet, etc. that can take in anything (e.g. Distance.fromFeet and <Distance>.asInches). Same for velocity, angular velocity, acceleration, etc.

Describe alternatives you've considered
Implementing these in our own team library: https://github.com/Team4028/2023-ChargedUp/tree/develop/src/main/java/frc/lib/beaklib/units

Although it worked, there is much to be desired and having wider, library-wide support would be extremely helpful.

Furthermore, we tried comments to denote units in places that didn't take in our own unit classes. However, this was clunky, easy to forget, and easy to ignore.

Additional context
An example of what I'd like is seen in our team library: https://github.com/Team4028/2023-ChargedUp/tree/develop/src/main/java/frc/lib/beaklib/units

I have no idea if this is really feasible but it would be extremely helpful.

[ThadHouse]

The reason we haven't done this throughout the entire library is the memory pressure. Unlike C++, any time you use a unit in Java, you'd have a memory allocation. The library is already up against a lot of memory and CPU pressure, especially on the roboRIO 1, and the effects units would have on those would likely cause major issues for teams. Java does not have an allocation free solution for units currently.

[ghost]

The reason we haven't done this throughout the entire library is the memory pressure. Unlike C++, any time you use a unit in Java, you'd have a memory allocation. The library is already up against a lot of memory and CPU pressure, especially on the roboRIO 1, and the effects units would have on those would likely cause major issues for teams. Java does not have an allocation free solution for units currently.

It would be nice if we could find some alternative, even if it's subpar, that doesn't use up memory allocation. Even an improved way to denote what units need to be passed into a function would be nice. Only way I could think of doing that would be an equivalent to typedef (i.e. typedef double meters and typedef double feet). Unfortunately typedef does not exist in Java and there is no equivalent without major overhead to my knowledge.

Alternatively: the classes could still be used, but their values wouldn't get passed into any WPILib classes; instead, they'd exist, and you'd put e.g. Distance.asMeters in places where you'd normally put a meters value. To some extent, that's already what I'm doing with my team's library (passing in meter values from a Distance to WPILib classes).

[calcmogul]

Alternatively: the classes could still be used, but their values wouldn't get passed into any WPILib classes; instead, they'd exist, and you'd put e.g. Distance.asMeters in places where you'd normally put a meters value. To some extent, that's already what I'm doing with my team's library (passing in meter values from a Distance to WPILib classes).

Is that different from https://github.com/wpilibsuite/allwpilib/blob/main/wpimath/src/main/java/edu/wpi/first/math/util/Units.java?

[ghost]

Is that different from https://github.com/wpilibsuite/allwpilib/blob/main/wpimath/src/main/java/edu/wpi/first/math/util/Units.java?

Yeah. Using the Units class still means you're generally unaware of what units the user passes in and are simply making an assumption that it's in the correct units. On the other hand, if a user passed in a Distance that could be constructed from a variety of distance representing units like Distance.fromFeet, the function that takes in that Distance can be assured that the user is, at the very least, aware of the units they're passing in and can more safely call Distance.asMeters() and pass that into whatever it needs to.

[Starlight220]

That still requires allocations. Which are the problem.

[ghost]

That still requires allocations. Which are the problem.

If the allocations are done solely by the user, they have control over how many are done. This shouldn't be done within WPILib itself.

If it makes more sense to have it then only be a user-defined class then that's probably fine.

[PeterJohnson]

If the interface requires a user make an allocation (create an object) to call the function, then it’s not a choice.

The only way that the number of allocations can be controlled by the user with such an interface is if the objects are mutable. Mutable numeric objects are generally a poor design practice since Java passes objects by reference and thus it becomes very easy to accidentally mutate what is logically a fixed value.