align utility function prefixes

[cjyetman]

We have a variety of validate_*(), abort_*(), and stop_if_not_*() functions here (I take significant responsibility for that, though the misalignment was mostly created when importing the functions from pacta.multi.loanbook.analysis and pacta.multi.loanbook.plot).

Additionally, through my experience building pacta.data.validation, I came to the conclusion of using assert_*() and is_*() as prefixes for such functions, for the purpose of keeping the prefixes reasonably short while also clearly identifying which functions throw an error versus those that return TRUE or FALSE.

@jacobvjk @jdhoffa I'd like to decide which style we prefer here and implement that universally in this package.

• related change stop_if_not_*() function names to affirmative assert_*() names #227
• related harmonize abort commmands to use cli::cli_abort() #228
• related harmonize warning commands to use cli::cli_warn() #229

[jdhoffa]

I don't have strong views on this, but since we are getting pretty semantic here, here's a few thoughts:

• I like is_*, it's clear that the result of that will be TRUE or FALSE
• I like stop_if_not_*, it's clear that if NOT, the result of that will stop the execution of the function
• abort_*, basically the same as stop_*, just pick one I guess. stop is probably slightly more idiomatic
• assert_*, is a bit ambiguous. It's not immediately obvious to me what happens if the assertion is not met. I could imagine either a stop or a FALSE might be reasonable outcomes.
• validate_* seems totally ambiguous to me

[cjyetman]

assert is commonly used in other languages like Python for this behavior (if TRUE do nothing, otherwise error), and e.g. is used in {checkmate} (just FYI that's where that comes from)

I think the logic is that is_*() evokes a question with an answer, TRUE or FALSE, whereas assert_*() evokes an action, error if not or continue without error.

[jdhoffa]

@cjyetman totally understood! It's used a lot in Rust too with the same functionality.

I was just putting on my incredibly nit-picky hat, and commenting on the fact that based exclusively on the name it's not immediately/ totally unambiguous, but of course with additional context/ experience it is more clear 😊

but anyway, I leave it to you and @jacobvjk to decide, I'm more than happy with any of the approaches

[cjyetman]

@jdhoffa @jacobvjk I believe this is still relevant, but it would be a nice-to-have to ease development and understanding of the code, not a critical task.

[jdhoffa]

Seems related to #54

[cjyetman]

yes, conceptually related, but targeted at different sets of thing that could be aligned