minor: Transfer HelpCommand::toString() to Utils

[paulbalandan]

Since HelpCommand is internal, I did not mind deprecating the previous.

[SpacePossum]

I would go the other way around, moving all document-generation related stuff to its own namespace.
This way we prevent the generic Utils in the root namespace to become a big collection of all sorts.
Unless I've missed some talk about this logic move

[Wirone]

@SpacePossum I suggested it here because It looks like serious boundary-break when you use CLI command's method inside fixers' logic 😅. Since it's a universal conversion, IMHO it fits well to Utils that already has similar methods (like camelCaseToUnderscore()).

[Wirone]

Thank you @paulbalandan 🍻

[keradus]

agree that XyzFixer should not call HelpCommand

Also, agee with @SpacePossum that we should not add any logic to generic-purpose Utils [it's like random root-level namespace, one doesn't know where to put sth? they made Utils that is having everything].

I don't understand why suggestion of Space to create dedicated class for document generation was not consider and PR merged without concluding on that idea.
IMHO this PR should be reverted.

[Wirone]

Utils was already in the repo, was not deprecated, and already had similar generic-purpose methods, so it looked like fine place to move that logic to get rid of weird coupling between fixers and CLI command. IMHO state of the code after PR is better than it was before, even if it's not perfect.

I don't agree it should be reverted, instead we can make another PR that would deprecate Utils and would introduce better place for methods moved in this PR.

I evaluated @SpacePossum's comment and provided my reasoning for merging as-is. It does not mean we can't change this decision 🤷‍♂️.

[keradus]

Utils was already in the repo, was not deprecated

not a reason to add any random logic to it and make Utils even bigger and more generic.

[keradus]

I evaluated @SpacePossum's comment (...)

would be awesome to give Space time to get familiar with your answer and allow for discussion rather than concluding to merge directly afterwards

[Wirone]

But seriously, what's the problem here? We have 1 new public method in internal class that is considered as improper place for it, instead of place that was even more improper 🤷‍♂️. Work was done voluntarily, can be refactored at any point. Is it really something that we should discuss that much? There are many open PRs waiting for your response, you could utilise this time better 😉.

[keradus]

god-object antipattern should not be feed with more spam into it.

so if i get poked in private to check the PR due to the concern, i put effort here and not in place that would take bigger benefit from it.

[keradus]

#7039

[SpacePossum]

Sorry for starting off this discussion as this wasn't my intent. Still think it would've been better to give a bit more thought about how the composition of the classes would ideally look like in the future. Than reviewing would also be more easy as a PR can been seen if it is part of the "bigger plan" or not. And please be considered when talking about peoples time as we all got to manage that as good as we can somehow. Anyway, for now all good imho 👍 Thanks keradus for 7039 :)