Open Hieuzest opened 9 months ago
这些指令或没有对应的service,或其service偏向internal不易使用
理应通过session.execute来执行以实现类似service的效果
为什么不是让这些插件提供对应的 Service,或将 Service 封装变得更易于使用,之后直接使用 Service 实现需求,同时插件本身的指令 Action 也调用 Service 实现需求而非在 Session 中直接实现?
command作为koishi三种跨插件调用之一(event,service,command),应当拥有更广泛的使用场景。
Command 之所以能独立于 Service,正是因为 Command 于 Service 的差异导致的,而差异的关键恰恰在于 Session 的存在,而 Session 的存在正是由于 Session 默认提供了包括 Bot、Guild 和 User 在内的多种信息。在没有这些信息需求的情况下,Service 无疑是比 session.execute()
更好的呈现方式。
因此,
session.execute()
调用;session.execute()
时为指令的存在及可用性等问题烦恼。综上,我认为 session.execute()
足够作为指令间重定向及临时触发其他插件逻辑的方法,但不足以作为插件互操作(Interop)的方式。将精力更多地放在 Service 生态的推广上可以使终端插件拥有更多 JavaScript 风格的、可选加载和可隔离的 API 可供使用,并最终使整个生态从中获益。
字符串操作很好玩吗,而且也不一定只有一个消息,也不一定是 retuen 的,你就说你想怎么处理吧, 你说你只是执行指令不管输出那你参数还得字符串拼接,如果包含特殊字符/用户输入,会不会出现bug或注入?
Describe the problem related to the feature request
目前我们有一些(管理类的)指令,如alias,plugin,command, shorturl等。这些指令或没有对应的service,或其service偏向internal不易使用。而这些指令本身,除了用于控制执行权限的authority/permissions外,与bot/session并无耦合,理应通过session.execute来执行以实现类似service的效果
但这其中存在以下几点问题:
<cmd> -h
的执行过程总无法与session解耦,应当优化。command作为koishi三种跨插件调用之一(event,service,command),应当拥有更广泛的使用场景。基于此,我认为我们可以:
对部分设计插件的一个显见的好处是,我们无需重复性的实现同一功能的command/service版本
Describe the solution you'd like
/
Describe alternatives you've considered
No response
Additional context
No response