Added withDeadline modifier

[Daniel1464]

Currently, a lot of teams use the Commands.parallel(), Commands.race() and Commands.deadline() static factory methods for parallel groups. However, Commands.deadline() doesn't communicate its purpose very well(it doesn't mention the word "parallel" at all, and it doesn't make clear what the deadline of the parallel group is). Even though the deadlineWith(soon to be called deadlineFor) modifier exists, it introduces inconsistency in syntax if a team uses the parallel() and race() factories(as it is an instance method).

Thus, a withDeadline() modifier is added to the ParallelCommandGroup class to allow for Commands.parallel(a,b,c).withDeadline(d). This solves the issues of syntax inconsistency while expressing the intent better to code readers. In addition, the parallel factory methods now have a return type of their respective class, which allows for this syntax to exist.

[github-actions]

This PR modifies commands. Please open a corresponding PR in Python Commands and include a link to this PR.

[spacey-sooty]

Note: I don't believe this is possible in c++ due to the use of CommandPtr.

Pretty sure it is

[Starlight220]

Note: I don't believe this is possible in c++ due to the use of CommandPtr.

Pretty sure it is

It can't be done in C++ due to the opaqueness of the underlying command type. Specific return types would cause object slicing issues when used (that's why CommandPtr was introduced).

---

Now onto Java:
I'm not a fan of this.

The return type opaqueness is intentional, to allow for encapsulation and any later implementation changes in a non-breaking way. There's little-to-no advantage to specifying exact command types, and it breaks on any changes.
There used to be type-specific decorators/overrides etc, it caused issues and was removed in favor of consistent polymorphism.

The added method itself doesn't add anything, imo. It doesn't use the fact that it's a parallel group. It's more verbose than the alternatives.

[Daniel1464]

I doubt that the implementation of Commands.parallel() will change in the future; at most, any overhauls to parallel groups will modify the existing classes and not new ones

[KangarooKoala]

My personal take- I agree that there's significant value in distinguishing the deadline command from the other commands. However, I also agree that it's good library design to keep the return types of the factories as an opaque Command. (This also ensures that we maintain parity with C++)

These two statements lead me to the idea: Add a Command withDeadline(Command deadline) to Command in Java (CommandPtr WithDeadline(CommandPtr&& deadline) && to Command and CommandPtr in C++) which is an alternate way to invoke deadlineFor(). The main downside is that deadlineFor() already exists and is more powerful (since it can accept variadic arguments). I think there's still value is adding an alternate order since depending on the situation it might make more sense to put the non-deadline command first, but I'm ambivalent.

@Starlight220 @Daniel1464 Thoughts?

[Daniel1464]

I think that probably would be a better implementation of my current idea.
Something like this?

Commands.parallel(a, b, c).withDeadline(d)

[Daniel1464]

/format

[Starlight220]

Re command.withDeadline(); that would be a good idea if there's enough use given the limit of one other command

I guess go for it?

[KangarooKoala]

Looks good to me, for what it's worth- One of the wpilib devs will also need to review this.

[Daniel1464]

/format

[KangarooKoala]

We should add a test for this to CommandDecoratorTest.

[Daniel1464]

/format

[KangarooKoala]

Looks good to me too, for what it's worth.