ideas

[kaikaibenkai]

• 检查所有 API 调用参数
  方便 debug 。

• 用户自定义事件
  包括触发、回调、错误处理，让 Event 成为真正的事件总线。
  极大方便地图开发。

• 游戏事件监听器单例化
  一种游戏事件只调用一次游戏内置的事件监听器，在唯一的游戏事件回调上调用用户创建的多个函数。
  方便后续拓展，节约游戏内核处理时间。

• 注释使用 EmmyLua 风格
  在 VS Code 中有更好的高亮和自动补全。

[0-0000]

1. 检查 API 调用参数对效率影响大，通常在 C 函数中才会检查参数，而且开发时期长作用不大，开发者应自行养成手动检查参数的习惯。
   目前 MiniExtend 提供的大多数函数是以常量作为实参调用的，或者泛型可变参数。
2. 这部分我可能会参照 qt 来完成应用。
3. ...
4. 现在除了我真的还有几个人在用 MiniExtend?现在的工作中心是开发更多功能，我希望能有其它开发者(而不是我)为 MiniExtend 使用 EmmyLua 风格。

[kaikaibenkai]

作为一个 runtime library 来说，不能要求用户学会什么

[0-0000]

我在强调一次，效率在 MiniExtend 中是非常重要的，你可以去测试检查参数类型和不检查的效率差。
我不太理解你说的用户是什么意思

• 如果用户指玩家的话，那么玩家是不会直接接触 MiniExtend 的，MiniExtend 也不会直接使用他们的输入，或者开发者手动将其转化然后访问 MiniExtend。
• 如果用户指开发者的话，那么开发者自己就要了解该传递怎样的参数，了解传递错误参数的后果，而这些在文档中已经尽可能地体现了。

[kaikaibenkai]

为避免混淆，用户指使用者，即地图开发者。

要知道，面向对象本来就是有损失的。

效率当然重要，但这不是构建逻辑松散的代码的理由。

除非有一套新的处理逻辑（ #16 - 3 ），否则，框架是不可能比原生效率高的。

除了使用体验，MiniExtend 并不能给用户带来什么。连参数类型都不检查，用户心理负担当然要增加。

毕竟连 PySide6 都要检查所有参数再调用 C++ ，而不是在调用 C++ 函数失败后才抛出异常。

[kaikaibenkai]

以我狭窄的见闻，并没有多少地图开发者关心效率（除非是游戏卡死）甚至有的连时间复杂度都不知道是什么。

所以，我自认为要走用户体验路线。

大佬接触深层次多年，关心的是时空复杂度。而走到这个层次的地图开发者，屈指可数。

[0-0000]

我不希望讨论成为辩论，如果你真的希望 MiniExtend 这样发展的话，你可以 Pull request 。
开发 MiniExtend 不仅要考虑对使用者，还要为考虑开发者考虑，目前能为 MiniExtend 发展提出建设性意见并为其编写代码的也只有我，注释等内容已经是比较详尽了的，我希望这些非主要内容能由其他开发者丰富。