Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use records in Java for classes with immutable data #7821

Open
Gold856 opened this issue Feb 25, 2025 · 3 comments
Open

Use records in Java for classes with immutable data #7821

Gold856 opened this issue Feb 25, 2025 · 3 comments
Labels
2027 2027 target type: feature Brand new functionality, features, pages, workflows, endpoints, etc.

Comments

@Gold856
Copy link
Contributor

Gold856 commented Feb 25, 2025

Rationale

Java records are a special type of class that allow you to create objects that contain immutable data in a much more terse way than with normal classes. The private fields, accessors, constructor, equals, hashcode, and toString are automatically implemented, with the accessors having the same name as the field. This means that we can drop the get prefix on several different accessors. If the behavior of any of the autoimplemented methods isn't desirable, they can be implemented manually to get the desired behavior. Even though we would end up manually implementing a few methods like equals or toString (the former is because of floating point, the latter is because of formatting floats,) records would still make the code for types like the geometry types less verbose.

In addition, you can use record patterns to essentially destructure data, although that's bordering on misuse of the feature. It seems Java might add destructuring support using records without the need for instanceof/switch, and it would be good to be prepared for such a future (if that future ever comes).

Goal

The idea would be to move most wpimath classes, specifically ones with immutable members, but others can be added if desired, to records. Some classes have accessors for non-fields, and we would drop the get prefix on those to maintain consistency. This would cause massive API breakage, and as such, is targeted for 2027.

@Gold856 Gold856 added the type: feature Brand new functionality, features, pages, workflows, endpoints, etc. label Feb 25, 2025
@SamCarlberg SamCarlberg added the 2027 2027 target label Feb 25, 2025
@PeterJohnson
Copy link
Member

What classes appear to be good candidates for this? Many of the math classes have significant custom functionality and as such I’m not sure how good of a fit records are.

@Gold856
Copy link
Contributor Author

Gold856 commented Feb 25, 2025

The pose, rotation, transform, and translation classes. They all have several immutable member variables and have substantial boilerplate that could be removed for accessing all the members, constructing the object, hashCode, and equals (sometimes).

@spacey-sooty
Copy link
Contributor

spacey-sooty commented Feb 26, 2025

What classes appear to be good candidates for this? Many of the math classes have significant custom functionality and as such I’m not sure how good of a fit records are.

You can still apply a lot of custom functionality to records, but as Gold said it cuts down on boilerplate. This also has the benefit of allowing us to use StructGenerator on many geometry classes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2027 2027 target type: feature Brand new functionality, features, pages, workflows, endpoints, etc.
Projects
None yet
Development

No branches or pull requests

4 participants