指令管理的优化建议

这个会在更底层的 cordis 中解决,未来会有例如 ctx.fs 等无副作用的 api。

代码层面的方案就是:指令使用插件名称,而不是其他过于常见的单词。当两个插件功能一样或高度重合,则不需要担心重复问题,因为在功能上本身就是重复的,这也是预期的。

PR‘s Welcom

5 个赞

哦哦 原来现在原名也可以禁用了!

3 个赞

我赞同将唯一指令名这段写入文档,其次如上面所述,中文指令名在接下来的版本将得到一个警告。

我想到一种可行的方法来解决你所说的"让开发者写出尽可能唯一的指令名":

  1. 将现有的标识符由原名改为插件ID.<原名>,如blockly.help,同时,为了向前兼容,在升级时创建一个别名"help"给"blockly.help"(如果占用失败弹警告或者直接终止)

上述更改需要以下前置更改:

  1. Config Migration:我们需要更新一次配置文件

但是目前来看,在没有执行这个方案之前,最好的做法还是将插件名称硬编码进插件内部。同时,原有硬编码的插件也不会因为migration这个行为而受到损失(blockly.help - blockly.blockly.help)

5 个赞

你说得对,可以限制开发者行为。但这一点我和梦梦卞过,结论是系统外副作用很难而且不应该被回收。

为什么?

首先,你如果尝试回收系统外副作用,那么一定会出现副作用的副作用。也就是它一定要一个地方记录产生的副作用。这样存在两个问题:1. 如果当前记录被外部应用程序更改,那么很可能记录的副作用就会产生错误。2. 那么我们如何回收副作用的副作用(也就是记录副作用的文件) 3. 如何界定副作用回收时机,比如文件读写,你如何界定文件读写已经完成,这个文件是否应该要删除…等等。所以我认为"ctx.fs"并不能保证无副作用/可回收的副作用,它保证的只是"系统内"可回收的副作用,也就是只能保证行为(占用文件等)副作用能在插件卸载之后被回收,而不能保证结果(写入了文件,影响了文件系统结构)的副作用能被回收。

5 个赞

so, cordis os when

4 个赞

肯定不行的啊 原名是唯一标识

2 个赞

I think he was referring the feature that we could disable the original name for triggering the command and use several aliases instead.

4 个赞

同意见。插件 ID 的唯一性有外部保证,这样的设计应该能完全消除开发者对指令重名的担忧,减轻负担。

但是在用户侧,因为用户仍旧用不带插件 ID 的指令名调用,故也仍应该对指令名重名有相应警告或错误,提醒用户编辑别名。


Koishi 目前的设计假定插件开发者应当且会负有给指令起好名字的责任,但社区内的插件作者开发经验差异很大。以我的使用经历而言,有相当多的活跃、优质的插件,其作者也并未意识到这份责任,中文名和简短指令原名俯仰皆是。另一方面,一些代码简单的插件基本处于归档状态,无法指望及时的更新。当它们重名时,要求插件作者来处理重名问题一定会非常低效,甚至无法推进。当然社区可以重复开发功能相同的插件来解决,但这也算不上是一个非常优雅的结局吧。

@Lipraty@shigma 关于 为何指令原名应当唯一 的论述都非常正确,但是 Koishi 或许自身可以做到系统内保障任意插件的原名路径唯一,而不下放这项任务到每一个开发经验差距很大的插件作者身上。


插件 ID + 指令名 代表某个插件指令的这个想法很直观,所以我不太确定没有采用这种做法是否有其他原因。不过既然有人提及了,我也就跟帖表达一下我的想法了(

3 个赞

谔谔,怎么吵起来了。请大家友善讨论。

2 个赞

最热闹的一集

2 个赞

没吵没吵

4 个赞

我也觉得没有吵起来呀:kissing_closed_eyes:

3 个赞

文化人的事能叫吵吗(

3 个赞

就我一个土狗:sob::sob::sob::sob::sob:

2 个赞

写了快 1000 字又给我删了。

大家的观点都挺好的。

2 个赞

这里是指,唯一标识可以不作为alias了

3 个赞

我有两个不同的插件,插件的每个指令我都加上了插件名前缀作为命名空间,已经保证了原名的唯一性。

但是我这两个插件分别在两个不同的平台使用,功能完全不一样,为了易用性,我需要给其中的某条指令设置别名 ”重置“。而重置这个功能在这两个插件中都有。

虽然我通过插件的过滤器设置好了这个插件只能在这个平台上用,但是别名似乎无法设置过滤器,它是全局的。

如果我禁用了其中一个别名,在那个平台上的那个指令就会无法触发。

现在我只能通过开两个 Koishi 实例来实现这一点。 :cry:

对于这样的需求有什么更好的解决方法吗?




顺便一提,其中的 help 指令我也设置了 ”帮助“ 作为别名

但是仍会触发 Koishi 原有的 help 指令,原 help 指令又找不到在哪禁用 帮助 这个别名,我只能把 help 插件给禁用了。

1 个赞

直截了当的解决方法:

  • 给 Koishi 提 issue,建议支持别名的过滤器(我觉得可以做)

可以喜人的解决方法:

  • 写一个重置服务,专门提供重置指令,然后两个插件分别调用这个服务定义重置时的行为
  • 由于重置指令只有一个,所以永远不会冲突
  • 如果有第三个插件冲突了,你让他也用你写的服务
2 个赞

在这个例子中,「别名的过滤器」中的别名实际上和现有的别名不是一个概念了

就像我在另一帖中写的那样,可以做个插件来实现上述的事情。(等我晚上摸一个

update:

commands怎么不给slot啊,纯schema也太难受了

呜呜呜果然我还是写不来社区插件,跑路了,姑且摸了一个,仅供参考

3 个赞

Feature: 支持别名的过滤器 · Issue #1369 · koishijs/koishi (github.com)

重置只是其中一个功能,还有其他类似“设置”、“帮助” 等常见的功能,如果做成服务或者插件的话应设计得通用。

也不知道可不可以通过服务或插件解决 :face_with_monocle:

3 个赞