Java Conditional Command

[GeeTwo]

Originally Posted by notmattlythgoe

GeeTwo, it works because getDistance() returns an object not a value. So the getValue() call on the object at the time of the comparison will get the current value.

OK, my poorly exercised OO brain gets it, but my better exercised procedural brain sees spooky action at a getDistance().

That suggests to me that you would want to have polymorphic forms of the command, including one which allows both operands to be objects. This could then be used to do things like (for example) returning the original drive direction by driving faster with the left wheel than the right, then equalizing after a

waitUntil(leftAxle.getDistance(), GREATER_THAN_EQUAL, rightAxle.getDistance())

completes. If you do this, you should allow either operand or both to be objects. For sanity's sake, a constructor using two numeric values could be created, but it should throw an exception telling the user that [s]he is trying to wait forever, or not at all.

[notmattlythgoe]

Originally Posted by GeeTwo

OK, my poorly exercised OO brain gets it, but my better exercised procedural brain sees spooky action at a getDistance().

That suggests to me that you would want to have polymorphic forms of the command, including one which allows both operands to be objects. This could then be used to do things like (for example) returning the original drive direction by driving faster with the left wheel than the right, then equalizing after a

waitUntil(leftAxle.getDistance(), GREATER_THAN_EQUAL, rightAxle.getDistance())

completes. If you do this, you should allow either operand or both to be objects. For sanity's sake, a constructor using two numeric values could be created, but it should throw an exception telling the user that [s]he is trying to wait forever, or not at all.

The command can definitely be expanded to accept different inputs. However I disagree with the constructor that throws an exception. Why give them enough rope to hang themselves when you can just not give them the rope at all?

[GeeTwo]

Originally Posted by notmattlythgoe

The command can definitely be expanded to accept different inputs. However I disagree with the constructor that throws an exception. Why give them enough rope to hang themselves when you can just not give them the rope at all?

Ease of debugging. An exception that tells you that one of the operands ought to be an object is more informative than a no such method error at compile. It can also be caught and allowed to run if that's what the programmer really wants. Sort of like a "do you really want to delete this? dialog.

[notmattlythgoe]

Originally Posted by GeeTwo

Ease of debugging. An exception that tells you that one of the operands ought to be an object is more informative than a no such method error at compile. It can also be caught and allowed to run if that's what the programmer really wants. Sort of like a "do you really want to delete this? dialog.

Its much easier to debug a syntax error because the method they are trying to access doesn't exist than allow it to get to the point that it runs and throws an exception.

[GeeTwo]

Originally Posted by notmattlythgoe

Its much easier to debug a syntax error because the method they are trying to access doesn't exist than allow it to get to the point that it runs and throws an exception.

Seeing the syntax error, the normal reaction (at least on my team) would be to check for a typo of a failed import, because these are the usual causes of our syntax errors after punctuation. It would take a longer time to figure out a syntax error than a "NeitherOperandIsObject" exception.

[notmattlythgoe]

Originally Posted by GeeTwo

Seeing the syntax error, the normal reaction (at least on my team) would be to check for a typo of a failed import, because these are the usual causes of our syntax errors after punctuation. It would take a longer time to figure out a syntax error than a "NeitherOperandIsObject" exception.

That's when the syntax error notes are helpful. They'll tell you that the method parameters don't match.

The method waitUntil(IProvidesValue, Operation, IProvidesValue) in the type ConditionalWaitCommand is not applicable for the arguments (double, Operation, double)

That's telling you that a method with that name exists and what it is expecting as the parameters. No need to run it and track down where an exception was thrown from.

[SamCarlberg]

Originally Posted by GeeTwo

My Java is a bit rusty, but won't this command in the DriveToLine instantiator:

        addSequential(waitUntil(drivetrain.getDistance(), GREATER_THAN, 50));

Get the distance from the drivetrain once during the instantiator, rather than sending a handle for the drivetrain.getDistance method to waitUntil()?

Yep. It would be better to pass a method reference

        addSequential(waitUntil(driveTrain::getDistance, GREATER_THAN, 50));

and call that method during each check.

Originally Posted by GeeTwo

OK, my poorly exercised OO brain gets it, but my better exercised procedural brain sees spooky action at a getDistance().

That suggests to me that you would want to have polymorphic forms of the command, including one which allows both operands to be objects. This could then be used to do things like (for example) returning the original drive direction by driving faster with the left wheel than the right, then equalizing after a

waitUntil(leftAxle.getDistance(), GREATER_THAN_EQUAL, rightAxle.getDistance())

completes. If you do this, you should allow either operand or both to be objects. For sanity's sake, a constructor using two numeric values could be created, but it should throw an exception telling the user that [s]he is trying to wait forever, or not at all.

This could be done with a few generic methods, i.e.

    public static <T, U> ConditionalCommand waitUntil(Supplier<T> left, BiPredicate<T, U> tester, Supplier<U> right)
    public static <T, U> ConditionalCommand waitUntil(Supplier<T> left, BiPredicate<T, U> tester, U right)

So you could just call

waitUntil(driveTrain::getDistance, GREATER_THAN, 50);

where

GREATER_THAN = (left, right) -> left > right

[notmattlythgoe]

Sam,

Any chance of getting some of these types of concepts into the WPILib at some point?

I'm really liking the method reference strategy.

[SamCarlberg]

I would be surprised if it made it in this year with kickoff so close.

It would also need to look similar in C++ with whatever it uses for lambdas and method references

[notmattlythgoe]

Originally Posted by SamCarlberg

I would be surprised if it made it in this year with kickoff so close

Yeah, I doubted anything additional would make it in this year. I meant more for future years.

[SamCarlberg]

Originally Posted by notmattlythgoe

Yeah, I doubted anything additional would make it in this year. I meant more for future years.

Maybe. It doesn't seem like a huge project but it might not be a priority for next year