[API 8] Resolve removal of get prefix on certain methods that didn't accept the change too nicely

[NickImpact]

Aiming to use this issue as a general repository of method names in the API that, following the get prefix removal, received confusing renames.

Please append any issues you spot to this ticket rather than creating a new one, so we can have a global repository and one singular issue aimed at fixing the problem. Also, please provide possible renames of the methods so they can be properly discussed.

---

Known so far:

EconomyService

• getOrCreateAccount --> orCreateAccount
  • accountOrCreate (zml) or createAccountIfAbsent (mbaxter)

Objective

• getOrCreateScore --> orCreateScore
  • scoreOrCreate or createScoreIfAbsent

[kashike]

e5717ac

[dualspiral]

aee5e7c for economy service.

Will leave this issue open for the time being for any other weird results from dropping get.

[dualspiral]

GameProfileCache now has methods such as byId, byName etc. I feel like these should be named find and overloaded if possible, or at least findById(...) etc. Thoughts?

[ImMorpheus]

GameProfileCache now has methods such as byId, byName etc. I feel like these should be named find and overloaded if possible, or at least findById(...) etc. Thoughts?

+1

Can we rename similar methods for consistency ?
StateContainer#statePropertyByName
Scheduler#tasksByName
Scheduler#tasksById
State#statePropertyByName

[dualspiral]

We should - open for comments but I don't want to leave this proposal too long.

[zml2008]

For GameProfileCache, how about a scheme like withName or named?

[NickImpact]

I'm more on the side of withX, as I can imagine id not coming across as straight as it should.

[dualspiral]

I'm not sure about with, as with is generally used to return an immutable copy of itself with a modified attribute.

Note that I have used find for the user manager - it's worth discussing that too as I'd argue is the same thing here. Also probably the same with account.

I've been thinking more about accountOrCreate and scoreOrCreate and I feel a little iffy about them because it doesn't seem natural to have nounOrVerb - I think that's why I went find in the first place. I think this is somewhere that we need to have a consistent policy.

@Zidane @gabizou any thoughts on how you'd like to handle this?

[dualspiral]

We should - open for comments but I don't want to leave this proposal too long.

Famous last words.

I've spent some time thinking about this and the more I look at it, the more I really dislike nounOrVerb(...) methods - it's jarring. My preference remains to prefix these methods that grab a result from a collection or collection-like objects should be findX. It's what we have on other objects such as defaulted registries and such. This includes things that have been renamed as part of this issue already, scoreOrCreate (get a score or create?) should really be findOrCreateScore, for example. Similar case with the econ service. The methods should still make sense in English.

find would match the registry querying etc. and I think it makes the most sense here. We can omit the noun if the object's interface name makes it clear as to what you're getting (so find on UserManager makes sense without "User", but find on Objective doesn't make sense without Score as Objective#find() could be construed to get an objective and not a score towards the objective.)

I'll go ahead and use find and findOrCreate unless anyone has a good reason as to why we shouldn't use find in these scenarios.

[dualspiral]

Nothing else has come up in the past month so I'll close this. It can be re-opened if more comes to light.