[反面教材] 自造 Handler 的后果 about application HOT 17 CLOSED

又是自造 handler, 操了.

停止自己自造 handler 这种愚蠢到爆炸的行为, broadcast control 十分强大, 具体的内容我会在今天晚上更新的文档里面说明, 就拿你这个例子

啊，那真是太棒了！i了i了

from application.

判断 MessageChain 中是否有 command 可以用无头参数修饰器来解决，那么今天的文档中是否会说明如何监听具体 command 并执行相关业务代码呢？要知道，command 是 bot 的一个重要组成部分，大多数 bot 都有类似的功能，所以，我还是希望能讲一下这种情况应该怎样处理。

本来这里的处理是要由模块 graia-ptilopsis 通过构筑标识链解决的, 所以今天的文档中不会包含这个部分(当然, 不排除这个模块突然有想法导致今天内发版的可能)

from application.

我知道你这个问题出在哪了, 这个问题我也在使用 atexit.register 时发生了.

你需要把那行愚蠢的 @bcc.receiver 去除, 然后在 __init__ 里面写:

bcc.receiver("GroupMessage")(self.group_message_listener)

问题很jb简单, bcc.receiver 被执行时, 传入的是他妈的一个还没被 classy 的 function, 其中的 self 极有可能导致了 RequirementCrashed 错误.

from application.

已经出了一部分, 另外两个我明天写

from application.

又是自造 handler, 操了.

停止自己自造 handler 这种愚蠢到爆炸的行为, broadcast control 十分强大, 具体的内容我会在今天晚上更新的文档里面说明, 就拿你这个例子

from application.

求求你们别他妈自己造 Handler 了, 我马上出一个文档给你们说一下该如何使用 无头参数装饰器(Headless Decorator)

from application.

求求你们别他妈自己造 Handler 了, 我马上出一个文档给你们说一下该如何使用 无头参数装饰器(Headless Decorator)

那您是建议我用 无头参数装饰器？这个更适合是吗？

from application.

求求你们别他妈自己造 Handler 了, 我马上出一个文档给你们说一下该如何使用 无头参数装饰器(Headless Decorator)

那您是建议我用 无头参数装饰器？这个更适合是吗？

你这个是纯属瞎几把又乱造了一个 Broadcast.listeners, 并且你这个也只是类似对 Listener 进行过滤, 使他在应有的地方启动, 这与我的设计中的无头参数装饰器是有一定的重合的, 并且如果你使用这个特性, 或许还可以通过后续更新中的, 命名空间(Namespace) 层面的无头参数装饰器更进一步的优化.

from application.

对于你后面这个 BotMessage: 赶紧!去死啊啊啊啊啊(╯‵□′)╯︵┻━┻

from application.

对于你后面这个 BotMessage: 赶紧!去死啊啊啊啊啊(╯‵□′)╯︵┻━┻

那我 BotMessage 要动吗

from application.

我只对你后面的这个自造 listener 集合批判, 两个设计都不够好, 但自造 listener 集合看起来已经成为一个非常广泛的现象了...我希望能改变这个怪现象

from application.

我只对你后面的这个自造 listener 集合批判, 两个设计都不够好, 但自造 listener 集合看起来已经成为一个非常广泛的现象了...我希望能改变这个怪现象

看起来还得继续增强文档 🤔 没有文档大家咋知道这么用嘛

from application.

我只对你后面的这个自造 listener 集合批判, 两个设计都不够好, 但自造 listener 集合看起来已经成为一个非常广泛的现象了...我希望能改变这个怪现象

看起来还得继续增强文档 🤔 没有文档大家咋知道这么用嘛

我也不知道该咋增强文档了, 但我有一点可以明确:

• Broadcast Control 可以带来几乎无限的扩展性和特性.

from application.

不如把一些愚蠢的操作列一下：

• 当你想要 xxx 时，何不试试 xxx？

坐等你 commit 文档了（（

from application.

判断 MessageChain 中是否有 command 可以用无头参数修饰器来解决，那么今天的文档中是否会说明如何监听具体 command 并执行相关业务代码呢？要知道，command 是 bot 的一个重要组成部分，大多数 bot 都有类似的功能，所以，我还是希望能讲一下这种情况应该怎样处理。

from application.

我知道你这个问题出在哪了, 这个问题我也在使用 atexit.register 时发生了.

你需要把那行愚蠢的 @bcc.receiver 去除, 然后在 __init__ 里面写:

bcc.receiver("GroupMessage")(self.group_message_listener)

问题很jb简单, bcc.receiver 被执行时, 传入的是他妈的一个还没被 classy 的 function, 其中的 self 极有可能导致了 RequirementCrashed 错误.

当我尝试这个临时的解决方案后，我发现在我发出 $test 后，bot 依然没有回应，控制台也没有任何响应

我上传了部分的源代码，由于 settings.py 含有敏感信息，暂时不便提供

jinzhijie-202008030754.zip

from application.

判断 MessageChain 中是否有 command 可以用无头参数修饰器来解决，那么今天的文档中是否会说明如何监听具体 command 并执行相关业务代码呢？要知道，command 是 bot 的一个重要组成部分，大多数 bot 都有类似的功能，所以，我还是希望能讲一下这种情况应该怎样处理。

本来这里的处理是要由模块 graia-ptilopsis 通过构筑标识链解决的, 所以今天的文档中不会包含这个部分(当然, 不排除这个模块突然有想法导致今天内发版的可能)

哦好的，希望能尽快出来 :)

from application.