You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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).
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.
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
, andtoString
are automatically implemented, with the accessors having the same name as the field. This means that we can drop theget
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 likeequals
ortoString
(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.The text was updated successfully, but these errors were encountered: