Refactor getCommandAndParents() into Command._getCommandAndAncestors() and use consistently#1939
Conversation
01251dc to
da5a499
Compare
|
This comment is just musing. No action items. I had considered these when I wrote the code, but was 50/50 on a couple, and willing to change.
Ok.
My concern was that ancestors might be more correct but less understandable to some readers. However, ancestor is certainly tree terminology. Ok. https://en.wikipedia.org/wiki/Tree_(data_structure) |
No, or at least not as strong as you describe. I did wonder about making the navigation more like an internal detail (so use the helper routine everywhere), but decided against that and have not changed my mind. The subcommand tree is navigable downwards using the So using the helper routine and array methods to replace manual loops is ok when it is an improvement or at least directly equivalent. But it is not appropriate when it requires extra steps or is awkward. |
lib/command.js
Outdated
| let candidateFlags = []; | ||
| let command = this; | ||
| do { | ||
| for (const command of this._getCommandAndAncestors()) { |
There was a problem hiding this comment.
Can this be a forEach? (I don't like the for ( of ).
There was a problem hiding this comment.
Could be if not for the early exit that is impossible with forEach. I guess this is one of the cases where iterating manually via .parent is more appropriate.
lib/help.js
Outdated
| const globalOptions = []; | ||
| for (let parentCmd = cmd.parent; parentCmd; parentCmd = parentCmd.parent) { | ||
| const visibleOptions = parentCmd.options.filter((option) => !option.hidden); | ||
| cmd._getCommandAndAncestors().slice(1).forEach((ancestorCmd) => { |
There was a problem hiding this comment.
No. Having to use the slice makes this too subtle for my liking.
There was a problem hiding this comment.
(Ok with the active variable changing to ancestorCmd though.)
lib/help.js
Outdated
| } | ||
| return parentCmdNames + cmdName + ' ' + cmd.usage(); | ||
| let ancestorCmdNames = ''; | ||
| cmd._getCommandAndAncestors().slice(1).forEach((ancestorCmd) => { |
There was a problem hiding this comment.
No. Having to use the slice makes this too subtle for my liking.
Ok with the active variables changing to ancestorX though.
This only ended up affecting a couple of the changes! I had seen them on first scan and feared there might be more, so wanted to explain my reasoning. Added comments on the lines of concern. |
shadowspawn
left a comment
There was a problem hiding this comment.
Was dubious about this but after working through my concerns, yup, ok!
Changes requested on three of the lines.
Only call when all elements are to be iterated. Resort to manual iteration via .parent in other cases.
Cherry-picked from #1938.
A purely cosmetic PR Introducing no functional changes or changes visible to the user.
Replaces
getCommandAndParents()withCommand._getCommandAndAncestors()Also changes the code to make use of the function whenever appropriate. (I thought it was a good idea after introducing
currentParentreplacingparentin #1938. I ended up getting rid of it and simply upgrading theparentsemantics, but who knows what changes to the parent resolution could be made in the future. It is better to keep the code for getting the ancestors in one place.)