v0.3.0 之前的一点设想与思考

[Wybxc]

从7月初发布以来，YiriMirai 一直保持着高强度的更新频率（除了中间我的电脑坏掉的那几天）。一个多月时间里，从 0.1.1 到 0.2.3，这个原本只是个人练手性质的作品，已经足以成为一个实用的项目了。

不过，从某种意义上来说，YiriMirai 也可以说是我“练手”的地方。在开发过程中，我本人的开发能力也有了不少提高。从这一点上看，就足以让我高兴了。

从 0.2.0 版本发布以来，我把重心放到了拓展模块的开发上。但是到现在为止，第一个拓展模块 trigger 还没有完工。虽然之前计划地十分美好，但就是在这样进行外围开发的时候，我发现了之前 YiriMirai 没能暴露出来的一些问题。

因此我决定，在完成 trigger 和 scheduler 的第一个可用版本，以及发布 0.2.4 之后，暂停拓展模块的开发，准备 0.3.0 版本。

计划上，1.0.0 版本将是第一个正式版，所以在这之前的 0.3.0 也依然是 pre-release 状态。

0.3.0 的第一个主要任务是重构底层的结构，引入一个新的类：MiraiD。MiraiD 是 Mirai 类的 Delegate Dispath 或者 Duplicate，用于支持自底向上地构建多模块的项目结构。这一设计的灵感来源于 FastAPI 中的 APIRouter。

伴随着 MiraiD 的，还有对事件总线的设计进行重写。目前，这一部分的构思还未完善。

[Wybxc]

接下来说一些我自己的顾虑吧。

随着开发的逐渐进行，我发现 YiriMirai 离原本描述里的“轻量级”越来越远了。上千行代码的模块，不算快的冷启动时间，以及为了易用性而牺牲效率的设计，很难说这样的一个库还能称得上“轻量级”。可以去代码里搜索一下 isinstance 出现了多少次，就能明白这是多么大的妥协。

而与之相反的，YiriMirai 在功能性上，还远远达不到摘掉“轻量”这个帽子的程度。我清楚地知道，自己离那些优秀的项目距离有多远。

同时，“低耦合”这一亮点也逐渐沦为一个噱头。为了降低耦合而抽象出的 SimpleMirai 类毫无用武之处，只是一个证明“这是一个低耦合的项目”的工具。

鱼与熊掌不可得兼。接下来的开发中，我会努力寻找这些问题的解决方案。也许之后，我会把这两个字眼从描述里拿掉，换成更加契合这个项目的词汇吧。

[Wybxc]

最后，是我个人的一点事情。

8月快要结束了。9月之后，我就要去北京，开始我的大学生活。

高考完的这个暑假，我几乎把全部的精力都放在了 YiriMirai 的开发上。暑假之后，能够留给这个项目的时间就没有那么多了。毕竟，大学对我而言还是未知的变数，我会选择怎样的道路，获得怎样的结果，都是未知数。

因此，之后 YiriMirai 的开发节奏会放缓，但我也不会就此放弃这个项目。毕竟这是我真正跨入开发者行列的第一步。

[Wybxc]

昨天晚上重新思考了一下 MiraiD 的设计
发现这玩意其实没啥卵用，功能性还弱的一批
所以 0.3.0 要出啥我已经不知道了……

[tuyunlei]

请问事件总线的设计，目前有什么想法吗？如果可能的话我也想参与进来，为YiriMirai做出一些贡献