Skip to content

Conversation

Daniel1464
Copy link
Contributor

No description provided.

@Daniel1464 Daniel1464 requested a review from a team as a code owner August 29, 2025 02:37
@github-actions github-actions bot added the component: wpilibj WPILib Java label Aug 29, 2025
@Daniel1464
Copy link
Contributor Author

/format

@calcmogul
Copy link
Member

I'm not a fan of this. We have too many constructor overloads as it is.

@calcmogul
Copy link
Member

/format no longer exists. You'll have to either run the formatter locally or apply the patch the lint-format job uploads.

Copy link
Contributor

@katzuv katzuv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess you could also overload getVelocityRadPerSec() and getCurrentDrawAmps().

@Daniel1464
Copy link
Contributor Author

I'm not a fan of this. We have too many constructor overloads as it is.

That's what I initially thought too, but the non-unit constructor overloads will get replaced in 2027 anyways.

@calcmogul
Copy link
Member

calcmogul commented Aug 29, 2025

but the non-unit constructor overloads will get replaced in 2027 anyways

Who said so?

@Daniel1464
Copy link
Contributor Author

Daniel1464 commented Aug 29, 2025

Who said so?

I'm assuming that in 2027 all of the non-units interop will be replaced since the GC overhead is no longer as big of a deal

@sciencewhiz
Copy link
Contributor

sciencewhiz commented Aug 29, 2025

Who said so?

I'm assuming that in 2027 all of the non-units interop will be replaced since the GC overhead is no longer as big of a deal

It's definetely been discussed for that reason, but due to 2027 needing to support FTC students there's also concern about requiring units everywhere raising the barrier to entry.

See slide 24: https://static1.squarespace.com/static/5d4b06a67cd3580001ded283/t/68067c54ddcaad1f7ddab1b5/1745255509954/2025+SystemCore+Software+Conference.pdf

@calcmogul
Copy link
Member

in 2027 all of the non-units interop will be replaced since the GC overhead is no longer as big of a deal

GC overhead is one factor, but not the only reason. WPILib discussed this topic internally before, and we concluded that we'd keep the double overloads around on the 2027 branch because the Java units library isn't as straightforward to use as the double API for inexperienced users.

WPILib C++ has only unit overloads because implicit conversions, operator overloading, and user-defined literals make the C++ units APIs look almost identical to the double APIs but with added unit type safety. It's more ergonomic and less verbose than the Java units library. Here's docs pages for comparison:

https://docs.wpilib.org/en/stable/docs/software/basic-programming/cpp-units.html
https://docs.wpilib.org/en/stable/docs/software/basic-programming/java-units.html

@calcmogul calcmogul changed the title Add units-supporting constructor overloads for physics sim classes [wpilib] Add units-supporting constructor overloads to physics sim classes Sep 27, 2025
@calcmogul calcmogul changed the title [wpilib] Add units-supporting constructor overloads to physics sim classes [wpilib] Add unit-aware constructor overloads to physics sim classes Sep 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants