Open shigma opened 1 year ago
本 RFC 用于讨论未来将要引入的官方装饰器支持。
本 RFC 只讨论 Koishi / Satori / Cordis 相关特性。请不要讨论与 Minato / Schemastery 相关的话题。
在 Koishi 中引入装饰器时,需要确保以下性质:
引入装饰器可以带来以下好处:
Service
Schema
Model
目前社区中已经存在 koishi-thirdeye 方案。但它基于旧版装饰器语法,不仅在接口上不兼容 Stage 3 Decorator Proposal,还大量包含了部分已经废弃的用法 (例如 Argument Decorator),因此不能直接使用。此外,该方案存在大型依赖,也不适用于 Koishi 的轻量化需求。
对于装饰器的支持计划分为多个阶段完成,每个阶段实现一部分 API。
class MyPlugin { @Event() callback1(...args) {} @Middleware() callback2(session, next) {} }
目前有两种设计方案,欢迎大家讨论。
Using
@Service('foo') class FooService { @Using('bar') bar: BarService constructor() { // 这里不需要继承和调用 super } }
Provide
Inject
@Provide('foo') class FooService { @Inject('bar') bar: BarService constructor() { // 这里不需要继承和调用 super } }
待定。
不在本 RFC 的讨论范围。未来可能会有独立的 RFC。
目前 TypeScript 已经完成了对 Decorator 的初步支持 (语法、类型检查),尚有部分功能待完善 (类型推导):
esbuild 在 0.18.4 版本后无法编译含有 decorator 的源代码,但计划未来支持:
对于此特性的开发需要等待上游生态完成并稳定后才会开始。
上游进度 (May 16, 2024)
本 RFC 用于讨论未来将要引入的官方装饰器支持。
本 RFC 只讨论 Koishi / Satori / Cordis 相关特性。请不要讨论与 Minato / Schemastery 相关的话题。
核心思想
在 Koishi 中引入装饰器时,需要确保以下性质:
优势分析
引入装饰器可以带来以下好处:
Service
基类,从而可以继承其他库中的类Schema
或Model
(尽管它们不在本 RFC 的讨论范围)现有方案
目前社区中已经存在 koishi-thirdeye 方案。但它基于旧版装饰器语法,不仅在接口上不兼容 Stage 3 Decorator Proposal,还大量包含了部分已经废弃的用法 (例如 Argument Decorator),因此不能直接使用。此外,该方案存在大型依赖,也不适用于 Koishi 的轻量化需求。
计划实现的 API
对于装饰器的支持计划分为多个阶段完成,每个阶段实现一部分 API。
事件和中间件
服务与依赖
目前有两种设计方案,欢迎大家讨论。
Service
/Using
。Provide
/Inject
。Service
函数。指令开发
待定。
配置声明 / 数据库声明
不在本 RFC 的讨论范围。未来可能会有独立的 RFC。
上游进度
目前 TypeScript 已经完成了对 Decorator 的初步支持 (语法、类型检查),尚有部分功能待完善 (类型推导):
esbuild 在 0.18.4 版本后无法编译含有 decorator 的源代码,但计划未来支持:
对于此特性的开发需要等待上游生态完成并稳定后才会开始。