先是导入
一直提是因为我认为此issue涉及上游cordis的缺陷，并且使得正确的代码无法得到正确的执行，因此其优先级应当高于所有应用层项目。
目前此问题影响不显著的原因是目前只有极少数（<20）插件有两个以上required services（比如：chat），且此问题为概率触发。
好了提完了下面尝试讲一讲我对service的想法。
我认为，对于绝大多数能够和用户直接产生交互的插件，其功能天然有被其他插件所调用合理性，即成为依赖的性质。至于其能否实际成为依赖，主要是看插件有没有预留对应的接口，即通过methods/events与调用者交互的可能性。而这一点的兑现是可以通过合理的写法，具体来说，通过完全的将指令注册和业务逻辑解耦，使具体的功能函数独立出来来实现的，并且这种兑现是几乎无代价的，因为对于一个复杂的插件，把所有逻辑写在command action anonymous本来也显得冗长，拆分出独立的函数是自然的。
纯粹使用指令来实现跨插件的调用也是不可行的。插件与终端用户的交互和与内部调用的交互的差异，主要体现在返回的不同上，对外返回的是描述性的渲染文本。对内则可以返回结构性数据或者一个error或者更简单的一个bool。此外更重要的是，指令面向session，而内部的调用并不需要一个session来输出。
在文档中，service原语被描述成具有通用性的上下文接口，其接口与实现可以独立存在，而事实上，由第三方的插件提供的服务几乎都是通常意义上纯粹的依赖，也很难具备拥有其他实现的可行性，与第一方的服务具有完全不同的性质。服务因为会注册到上下文，其注册名称通常都较插件名、指令名更加简短易读，这在目前还好，但倘若（经由上述的逻辑），绝大多数插件都可以为了支持被调用而成为服务，那么服务的命名空间可能也会重复，以至于产生迷惑抑或是提供注入的可能。
而目前的koishi体系里，无论使用何种形式描述插件间的依赖关系，用来确认依赖存在的using都是必须的，所以我其实相当希望扩大using的范围抑或是支持其他的、用以描述依赖的概念。
差不多已经不知道在说什么了，到此为止，并没有想要任何feature的意思x
我也好想成为猫猫啊（？）
1 个赞
感谢你的解读。你之前提的 issue 我已经看到了，不过由于发版排期的原因，还暂时没有时间复现，我会尽快处理的。
2 个赞
其实很早就可以using(‘command:foo’)了吧
你这么想的时候已经变成猫猫了，这就是超时空猫猫的力量（不是
1 个赞
是我没有表达清楚。这样想来，我当时使用子服务语法的时候，其实是using了一个服务下的多个子服务，也就是其实是遇到了引入中的问题，只是我当时并没有意识到。后来我就把这种写法一概删去了。
救世猫猫！
1 个赞