hundun

看了下英文下描述`组合模式`也会使用child，那就保持`@ChildCommad`命名。测试里的Parent改名Container减少歧义。

另外现在这样，`CompositeCommand`间可以进一步嵌套“父节点-若干子节点”关系形成树状。不知道要不要设计上就禁止，区分出'SubCommandGroup'应该有利于实现这点。

不过单看“XX助手”场景，有的功能点可能由SimpleCommand提供，所以需要的是能混合组合SimpleCommand和CompositeCommand 的工具。从这个角度来看，`SubCommandGroup`应该支持组合Command，也就包括支持`SubCommandGroup`间嵌套成树状。

> `SimpleCommand` 实际上是只有一个子指令的 `CompositeCommand` 看了下代码， `SimpleCommand` 和 `CompositeCommand`只是平级的关系啊。是想说`SimpleCommandSubCommandAnnotationResolver`是一种findSubCommands + validate的结果只有一个子指令的Resolver吗？ 另外我还是不太理解你说的兼容性和复用性指什么，能更具体的说明吗？

@Him188 > 我认为造一个其他概念而不要用 `CompositeCommand` 比较好 我的理解是要让 `CompositeCommand` 不变，使其和`SubCommandGroup`有如下区别 ||成员函数作为子指令|得到成员属性提供的子指令| |----|----|----| |SimpleCommand|√（仅对`@Handler`）|x| |CompositeCommand|√（仅对`@SubCommand`）|x| |SubCommandGroup|允许 or 不允许？|√（仅对`@CombinedCommand`）| ------ > 开发者用 SubCommandGroup 写, 然后 CompositeCommand 可以使用这个 group 是指变成这样吗，那不就又没区别了？ ||成员函数作为子指令|得到成员属性提供的子指令| |----|----|----| |CompositeResolver|√（仅对`@SubCommand`）|√| |SubCommandGroup|√|√（仅对`@CombinedCommand`）|

> `SubCommandGroup` 是对 `SubCommand` 的集合, 没有主指令名称, 它不能独立使用. `CompositeCommand` 拥有主指令名称, 包含一个 `SubCommandGroup` 时就包含了它的所有 `SubCommand`. 这样拥有最高的实用性? 懂了

1. `AbstractSubCommandGroup`是接口`SubCommandGroup`的一种实现，实现方式是交给`SubCommandReflector`计算；`AbstractSubCommandGroup`不是Command，即不能独立使用。 1. `@SubCommand`是protected于`CompositeCommand`的，故`AbstractSubCommandGroup`需要自己的注解，暂时使用`@AnotherSubCommand`。是否应该让`@SubCommand`变为public供两者统一使用？其他`@AnotherXXX`同理。 1. 为了识别各种`@AnotherXXX`，需要新的Resolver——`GroupedCommandSubCommandAnnotationResolver`，且SubCommandAnnotationResolver需要变为带泛型参数。 1. `CommandReflector`理解成两部分功能：一是反射出子指令，委托给`SubCommandReflector`；二是反射出子指令以外的Command属性（目前仅`Usage`）。

> 我觉得可以把那些 `@SubCommand` 复制到新抽象的 SubCommandGroup 中并 public. 将旧的标注 `@Deprecated(level = HIDDEN)`. 这样 Kotlin 用户只需要修复 import (因为 Kotlin 引用非直接父类的内部类需要带外部类类名), Java 用户无需更新. 即使已经(level = HIDDEN)且`CompositeCommand extends SubCommandGroup`，IDE还是会认为用户在试图使用父类的`@SubCommand` 并报错。`import …SubCommandGroup.SubCommand`未被使用，用户需要显式写成`@SubCommandGroup.SubCommand`。 计划开发期间真实移除`CompositeCommand.SubCommand`防止增加多处改动，晚些时候再讨论是否恢复为`@Deprecated`  类似问题的[issue](https://youtrack.jetbrains.com/issue/KT-14059)已被记录为kotlin...

x Kotlin 用户只需要修复 import √ Kotlin 用户修复为显式使用`@SubCommandGroup.SubCommand` 这样？因为我看IDEA自动补全也是选择补全为这样（指以前CompositeCommand.SubCommand还未废弃的时候），是因为这样也更符合编码规范吗？

还可以有一种过渡期的方案。 mirai只提供plugin.getCommandRootPermission()，但不作为Command构造参数默认值，则： 1. 已有代码行为不变，默认使用plugin.getRootPermission()； 2. 新写的插件在Command构造时主动使用plugin.getCommandRootPermission()，新增`notice权限`使其变为可控，在用户手册告知： > 若继续使用`${plugin_id}:*`则行为和旧版一样：赋予所有command权限，notice权限不可控（常开）； > 若改为使用`${plugin_id}:command.*`，则command权限和notice权限可分别控制。