Open lulu2002 opened 1 week ago
Thank you for bringing this to my attention. Yeah, I'm aware that the sibling implementation is not as comprehensive as it should. I think this goes back to the fact that we may not fully agree on who is a sibling of who :P
Nonetheless, the issue you point out is valid. I'll migrate this implementation when I get a chance. Thanks.
We can agree that in this case help is a sibling of reward set, and I already told you this issue before
I encountered an issue with the command resolution when using the
help
command in the current framework, which can resolve similar commands throughSiblingCommands
,ChildrenCommands
, and their combination viaRelatedCommands
. However, this structure has a flaw when commands are registered separately across different classes.For example, consider the following scenario:
In Class A:
In Class B:
In this case, the
/base help
command does not retrieve thebase reward
commands, because when checking thesiblingPath
, the path forbase help
is"base"
, while the path forbase reward get
is"base reward"
. As a result, neithersiblingPath
norrelativePath
returns the full command help I expect.Temporary Solution:
To resolve this issue temporarily, I implemented my own custom
Help
handler, using the following code:I also used the following helper to retrieve the sibling path:
This solution filters commands based on the
siblingPath
and usesstartsWith
to retrieve all related commands.Request for Enhancement:
I believe it would be highly beneficial for the
Lamp
framework to natively support such functionality, allowinghelp
commands to resolve all relevant commands, even when registered separately across different classes. This enhancement could improve the flexibility and ease of organizing command registration.