Daniel Chen
Daniel Chen
Looks good - I have a couple of suggestions: 1. When the javac plugin gets merged, a plugin should be added that makes sure the return types of switchTo(), switchFromAny(),...
I think the safest bet here might be a "scope function" of sorts. Such as: ``` CommandScheduler.withInstanceOverride(() -> { // do tests here }) ``` The advantage here i think...
> * ~Fits Kotlin idioms~ (This is just a fun observation and a very very low design priority) Lol i actually wasnt designing it for this purpose, just thought that...
For the java version, would it be a good idea to include methods for returning stuff in the java units library, or should the only return value be doubles?
Sure then. I don't think the units api rewrite does anything on the performance side of things though(just adds support for more methods that weren't possible w/ java's generics system).
Thinking about it, I think that for java we can probably mimic the simulation classes' methods(getVelocityRadPerSec(), getPositionRad()) as well as a getPosition() method that returns an Angle
Oh btw why is there still the org prefix in front of wpilib? Like why not wpilib.commands2 instead of org.wpilib.commands2?
> 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...
> 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