Rename `Timer::paused` to `Timer::is_paused` and `Timer::finished` to `Timer::is_finished`

[mgi388]

#15962 aligned public apis of Time, Timer and Stopwatch.

Stopwatch::paused was renamed to Stopwatch::is_paused.

But Timer::paused was left as is for some reason (couldn't find why), and also even though it calls Stopwatch::is_paused underneath:

bevy/crates/bevy_time/src/timer.rs

Lines 326 to 328 in 4051465

	pub fn paused(&self) -> bool {
	self.stopwatch.is_paused()
	}

1. So I think we should rename Timer::paused to Timer::is_paused, leaving Timer::paused throughout 0.17, and removing it in 0.18.
2. Similarly for Timer::finished -> Timer::is_finished.
3. I note there is Timer::just_finished. I honestly don't know about that one. I think Timer::is_just_finished probably works and follows the rule, but I could also see Timer::just_finished continuing to make sense with just_ being its own category of predicate naming similar to names like has_ or must_.

I've left the "ready for implementation" tag off until some bike shedding can happen on item 3.

[FlippinBerger]

I'm happy to tackle this one if we can get some more context based input on list item 3 above. Personally I vibe with keeping it as Timer::just_finished since that already clearly states what is happening and prepending is muddies the message a bit IMO. Timer::is_just_finished doesn't roll off the tongue or add context the same as the change from Timer::finished to Timer::is_finished does.

We also have prior artwork here for utilizing just as it's own category predicate in input events where we have just_pressed

[LikeLakers2]

3. I note there is Timer::just_finished. I honestly don't know about that one. I think Timer::is_just_finished probably works and follows the rule, but I could also see Timer::just_finished continuing to make sense with just_ being its own category of predicate naming similar to names like has_ or must_.

Since it's querying the state of the timer, just as the others are, I believe it should be renamed to include the is_ prefix too. This not only ensures consistency, but makes it easier to find once the user finds is_finished.

That said, I'll admit is_just_finished doesn't quite sound right. Perhaps is_finished_this_frame?

[FlippinBerger]

Since it's querying the state of the timer, just as the others are, I believe it should be renamed to include the is_ prefix too. This not only ensures consistency, but makes it easier to find once the user finds is_finished.

My only counter point is that bevy currently runs all gamepad/keyboard input through is_pressed and just_pressed so I feel like we have prior artwork that all new users will see very quickly when they're working through their first few examples while learning, so I don't think discoverability will be an issue. Plus the docs.rs page and any modern IDE / lsp shows all your methods, and for a struct with < 25 methods I wouldn't be too worried that it's hard to discover.

I feel like just_finished is concise, descriptive and my preference, but if we change it here we should probably also go change it in the input code as well.

[LikeLakers2]

@FlippinBerger I believe that consistency should win out here - as it helps those who decide not to look at the docs and instead rely on auto-complete (such as intellisense), without causing undue burden on existing users or new users who decide to look at the docs.

Plus, we're already changing the names of certain functions... so I don't quite understand the "prior art" argument.

[FlippinBerger]

Yeah I agree with you on the consistency. The prior art argument is that we already have this same pattern being utilized in other crates and I more brought it up to say we either need to leave just alone or visit a rename on the input methods as well to keep the full project consistency going. Autocomplete is going to get you there regardless once you type finished or paused so I think either way the community settles on will be the same end result for usability.

[LikeLakers2]

@FlippinBerger For what it's worth, I also think we should rename the input method stuff too, to keep it consistent but descriptive.

Side note: If we want to keep the old names as deprecated aliases for the new names, I wouldn't be opposed.