重构兼容性问题
LasmGratel opened this issue · comments
Core 太臃肿，很多功能都不需要
API天天更改导致每次更新都要重构一万遍 特别不适合长期维护
建议还是把 Protocol 有关部分的基础封装单门拆出来，什么 Event Bus 和 Coroutine 相关的东西放在其他地方
我从 mirai 1.1 版本就开始用了，每次你们更新我都要花五六个小时的时间去迁移排查
还有协议相关内容能否单独更新，独立使用
还有 MessagePacketSubscribersBuilder 被重命名成 MessageEventSubscribersBuilder 了，reply函数也不知道跑哪去了
我不知道这样天天改有什么意义，这是一个不小的库了，应该明白少重构的道理，多标记 @deprecated 少重构
现在就是开发者炫技的工具，而不是一个真正带来长期应用价值的程序
2.0-Mx 是 pre-release 版本没有兼容性保证并早在 2.0-M1 就说这是重构, 你可以选择不更新. 2.0-RC 起才有兼容保证.
mirai 底层就用协程, 不可能不带协程库. 协程是 Kotlin 语言级特性. 而在 Java 不需要考虑协程.
事件是必须要提供的. 否则你如何得到消息事件.
协议底层修改更频繁而且实用非常复杂, 只是你没有看到而已. 如果真的只暴露协议给你, 你很大概率不会用, 而且每个版本都要改.
例如 MessageSource 是内部重构了三遍才得到的这个 API, 群和私聊的发出和接受, 在线和离线全部在协议上不同, mirai 内部有十几种实现, 你难道要自己处理这些吗?
群图片和好友图片内部区别很大, 是 mirai 帮你处理了 ID 才能提供简单 Image 接口.
mirai 马上要支持更多来源的临时会话, 前几天研究过, 也有十几种接口, 你希望每个都来你自己处理吗
拆模块会大幅增加 mirai 要做的工作.
还有 MessagePacketSubscribersBuilder 被重命名成 MessageEventSubscribersBuilder 了，reply函数也不知道跑哪去了
我不知道这样天天改有什么意义，这是一个不小的库了，应该明白少重构的道理，多标记 @deprecated 少重构
现在就是开发者炫技的工具，而不是一个真正带来长期应用价值的程序
这是在 2.0-M2 被弃用的, 因为 Kotlin 编译器不支持, 2.0-RC release note 清楚写到你需要依次升级 2.0-M1 -> 2.0-M2 -> 2.0-RC
那请您告诉我哪个版本可以稳定用下去。
就按前几天分片消息解析来说, 内部接口几乎全改了, 而你用的 sendMessage 还是那个 sendMessage
为什么要全改掉？原来的不能用？还是QQ协议大变动？
为什么要全改掉？原来的不能用？还是QQ协议大变动？
原来的不能用, 协议比你想象得复杂很多
我昨天就想在 IMirai 接口提供底层 API, 但我发现是在过于复杂而无法对消息相关提供
你说的都没错，可是旧版不是登陆不上就是发不了图片/发不了信息
因为你的协议更新和core是绑定在一块的
如果我想要稳定的协议体验就要更新到最新的dev版本，这岂不是很搞笑
我不想要各种炫酷的功能，也不想要更优化的API 或者DSL 或者什么什么 这些都没用
一个稳定的机器人要求稳定的API 而我在一年内都没有看到稳定版的出现
我甚至不需要你的底层代码写的有多好
1.x 就是稳定版
如果我告诉你1.x已经没法发图了呢？
进行 2.0 重构是因为内部架构过于混乱导致非常难开发新功能
如果我告诉你1.x被封号的几率特别高呢？
那现在的内部架构就不乱了吗？2.0的会让你觉得特别清晰一目了然？
我觉得你都没有自信说2.0会让新功能的开发更加方便。issues下面那么多功能申请你确定2.0就会更快的完成了？
或者说真的有必要实现那么多功能让它变得无比臃肿，最后你也没法维护导致弃坑？
你好, 这个自信我是有的
所有维护者写这东西并不是为了你, 而是出于自己的兴趣
那你可以去找 Vue 作者谈谈。
不走程序了。
我不是该软件的使用者，但是作为一个大厂程序员，我绝对不可能忍受一个api在没有必要原因的情况下，没事干就把已有的接口随意的删除，更改名字和方法签名。
你的做法炫技很爽，但是，你所做的一切都是为了你自己，你从来不考虑到使用的人。没错，这是个gpl软件，用这自担。但这不是你因为你自己的炫技，给他人增加无谓的工作量的理由。
在工作中，如果有一个rpc接口，因为你的服务天天不打招呼就升级，改接口名字，签名，导致这边的服务调用失败，半夜报警，流量锐减以致投诉。那么很快你就会被我在工作群里面狂喷，你的leader也会在事后训斥你，这是我是你同事的情况。
如果我是你leader，你的行为造成了其他部门大量的不便甚至影响公司业务，你必被我喷到十八代祖宗都没，必被职场PUA，今年你的年终也没了，甚至直接滚蛋。
耗子尾汁。
gpl软件不是你我行我素的理由。
你再多再复杂的功能，你不懂什么叫隐藏细节？什么叫封装？在更新你的版本以前，建议多看看设计模式，否则喷你的只会更多。
我觉得没办法和你交流. 我已经做到了我该做的----
- 2.0 重构发布的是 pre-release 没有强制要求更新
- 2.0 解决了 1.x 的架构问题
- 2.0-RC 起会提供源码和二进制兼容
而你却希望我在 1.x 的屎里每天委屈自己为你兼容
? 有必要原因啊, 每个修改都有原因
java的Thread的stop, suspend, 等方法，从java1.5一直保留到了java 11，期间经历过10年，为什么没人改，你应该知道的。
我也没法和你交流，毕竟一个不注重真正的开发体验和用户体验只顾自己写的爽的开发者道路也走不长远
很明显我一直都在考虑体验
1.x 的代码是我刚学习 Kotlin 写的, 质量非常差, 是已经在实践过程中遇到了阻碍后续发展的问题
天天让人build failed，你在考虑你🐎的体验呢吧。
考虑体验的方式是尽可能不改旧接口的情况下添加功能，而不是字节爽。
很显然，你考虑的是自己的体验。
行了行了知道你在学习 Kotlin
学到啥就往软件里用啥
u1s1，mirai-http的api不香吗
由于俩人已经开始不友善, 我无法继续解释. 我在这里说明:
- mirai 1.x 的代码内部质量很差, 开发组几人都认为很难继续维护, 因此决定重构
- 1.x 还有一些设计原因, 如
MessageSource不兼容分片消息, Contact 架构不兼容陌生人和临时会话, 消息架构无法支持序列化等 - 2.x 重构现在已经完成, mirai 指定了版本更新策略, 在后续版本升级会保证源码兼容性至少两个版本, 二进制绝对向后兼容
补充: 2.0-Mx 的多个版本都有提供 @Deprecated 迁移方案
所有维护者写这东西并不是为了你, 而是出于自己的兴趣
曾经我在一个群吐槽说DSL的设计很蠢，DSL应当基于抽象好的接口来实现，你可以查看Kotlin内部的api，这样的例子比比皆是，连Ktor都提供了Module，但是那时您说“明明有不用DSL的方式，只是他不知道，如果他在我的群我就给踢了”，接着你给了我一个依然使用DSL实现的snippet，我当时看你的源码的时候就发现了类的职能混乱，代码炫技，这不是坏事，平时大家都喜欢写炫技的代码，写的时候随着开心就行不动脑子，但是既然你收获了star，fork和reputation，你就有责任去把这个工具做好，对于app来说“做好”就是app的易用性，而对于类库来说“做好”就是良好的API和抽象，1.x的逻辑写起来耦合度极高，不得不把什么都放进DSL里，以至于我不得不自己在您的DSL上面造了一个巨大的命令轮子，并且没有使用除了sendMessage和subscribeAlways以外的任何多余API，另外你还宣传过“开发者有权拒绝你使用mirai框架”而就我所知你所采用的AGPL V3协议没有任何权利和权力拒绝某个用户使用，如果你不知道的话，我可以告诉你，设计类库首先应当设计接口，之后根据接口去设计实现，而接口长什么样子不应当更改，如果你不懂的话，我推荐你看一本叫做《代码整洁之道》的书，写库并不是想办法炫技（炫技大家都会，用上自己所知道的一切API和一切的语言feature，就可以写出常人难以理解的库），而开源更不是过度自信和自我的借口（为什么这么说？详见上文两点），开源软件值得尊敬建立在开发者和用户互相尊重的基础上，如果人人都认为开源软件出于兴趣就可以妄自尊大（重复：为什么这么说？详见上文两点），那么开源社区迟早毁于一旦，”开源“二字并非抵御反对声音的银弹，“开源”也不应当有优越感，共勉（另外说一点，我最无法理解的是您为什么要写一个叫做->的函数，这让我不得不发笑）
我承认 1.x 那时有很多 DSL 且没有很好文档, 现在 2.0 刚刚提供了文档并推进了其他的更简单一些的方式
倒不如说就是因为 1.x 有过多不好的设计, 才会有 2.0 的重构. 消息事件下的那些 reply 方法就是目前 Kotlin 编译器不支持的东西. 在 1.x 通过一些特殊手段实现了, 而在最近 Kotlin 1.4.20 后发生了兼容问题. 因此在 2.0 为了稳定性把他们删除了
我觉得我会滚去用 mirai-api-http
我觉得我会滚去用 mirai-api-http
真的服了 居然有人觉得手动拆几十种byte[]更好
以前coolq就是一个string，CQCode.extract分析，但是事实证明是coolq没少因为qq更新出现消息解析bug，用了一年十几次因为各种更新出现各种空字符、整句话一个空格、CQCode解析混乱，mirai虽然source导致不能分片等以及还是不够优雅，但是从来没有因为Message系列的功能设计出现解析bug
PS：居然还有睿智用公开API改名字被投诉这么可笑的混淆视听来证明什么，不通知别人就改名字怎么都是你的错误好吧，Mirai的2.0里程碑都不知道pin了多久了 而且自从上了2.0的dev preM 几天之内连着发了十几个版，所有修改都明确写了该如何移植。更不用说基本所有软件的1.x→2.0都是解决初版设计不合理的问题的 必然出现api修改，居然还拿着那种臃肿的大厂领导驱动式项目说事
mysql 8直接引入了完全不兼容的登录协议
elastic6直接废弃type
java禁止违规的反射访问
有问题吗？
Mirai的开发者有权拒绝你使用mirai框架
git不能拉黑人真的便宜了某些人
（另外说一点，我最无法理解的是您为什么要写一个叫做->的函数，这让我不得不发笑）
这就是我刚学习 Kotlin 时候写的代码, 因此我想把它改掉, 至少要为了稳定性减少这些花哨的东西
“开源”也不应当有优越感
我没有因 mirai 开源获得优越感, 我所说 "所有维护者写这东西并不是为了你, 而是出于自己的兴趣" 是因为 mirai 1.x 的代码是在太渣, 我作为发起 mirai 项目的人之一希望能将它维护得很好才打算重构, 而即使我耐心解释了为什么重构, 他也无法接受, 并一直责问我为什么不提供兼容性... 因为就你所说, mirai 1.x 那样的质量已经没办法提供兼容性了
虽然 2.x 代码仍然不一定好, 但至少以我的垃圾水平能知道它比 1.x 更容易维护一些, 至少现在有文档而且同样有兼容性保障
真的服了 居然有人觉得手动拆几十种byte[]更好
以前coolq就是一个string，CQCode.extract分析，但是事实证明是coolq没少因为qq更新出现消息解析bug，用了一年十几次因为各种更新出现各种空字符、整句话一个空格、CQCode解析混乱，mirai虽然source导致不能分片等以及还是不够优雅，但是从来没有因为Message系列的功能设计出现解析bug
PS：居然还有睿智用公开API改名字被投诉这么可笑的混淆视听来证明什么，不通知别人就改名字怎么都是你的错误好吧，Mirai的2.0里程碑都不知道pin了多久了 而且自从上了2.0的dev preM 几天之内连着发了十几个版，所有修改都明确写了该如何移植。更不用说基本所有软件的1.x→2.0都是解决初版设计不合理的问题的 必然出现api修改，居然还拿着那种臃肿的大厂领导驱动式项目说事
mysql 8直接引入了完全不兼容的登录协议
elastic6直接废弃type
java禁止违规的反射访问
有问题吗？Mirai的开发者有权拒绝你使用mirai框架
git不能拉黑人真的便宜了某些人
- “Mirai的开发者有权拒绝你使用mirai框架”，你的自信从何而来，要么你给出相关许可证的依据，要么选择闭源，最终解释权归mamoe所有，要么就不要说这种毫无意义的话
- 你的比较前提是不成立的，mysql java等每个版本都足够稳定并且易用，也就是完全可以留在旧版本不用新版本，而且相比之下，Java API改动频率是多少，占比是多少？而mirai 1.x的体验相比之下是多少？请问你的这个比较是成立的吗
一句总结，爱用不用，没人有义务满足用户的任何需求。
一句总结，爱用不用，没人有义务满足用户的任何需求。
同样的，AGPL v3协议下的库没有权利拒绝任何用户使用，如果你能理解到反对声音大多源于这个高高在上的态度，那么其实也不会闹得很僵
一句总结，爱用不用，没人有义务满足用户的任何需求。
同样的，AGPL v3协议下的库没有权利拒绝任何用户使用，如果你能理解到反对声音大多源于这个高高在上的态度，那么其实也不会闹得很僵
代码是按AGPLv3授权的，但是，我们可以拒绝提供一切支持。
一句总结，爱用不用，没人有义务满足用户的任何需求。
同样的，AGPL v3协议下的库没有权利拒绝任何用户使用，如果你能理解到反对声音大多源于这个高高在上的态度，那么其实也不会闹得很僵
代码是按AGPLv3授权的，但是，我们可以拒绝提供一切支持。
请勿偷换概念，当初说到的拒绝使用和拒绝支持并非一个意思，也请勿埋怨我纠缠在这里不放，毕竟第一次贵库作者宣传“如果我在他的群里就直接踢了”，之后却承认DSL的设计非常不成熟，最开始声明“有权利拒绝使用”，现在您又在这里说“有权利拒绝提供服务”，你可以认为我一个人的不满是无济于事的，因为mirai的用户早已上千，缺不缺我一个无伤大雅，但是既然贵库的主要contributor都声明了该发言着实不妥，您为什么要在这里偷换概念，顾左右而言他呢？
一句总结，爱用不用，没人有义务满足用户的任何需求。
同样的，AGPL v3协议下的库没有权利拒绝任何用户使用，如果你能理解到反对声音大多源于这个高高在上的态度，那么其实也不会闹得很僵
代码是按AGPLv3授权的，但是，我们可以拒绝提供一切支持。
有问题吗？
Mirai的开发者有权拒绝你使用mirai框架
git不能拉黑人真的便宜了某些人
Originally posted by @Alceatraz in #850 (comment)
真的服了 居然有人觉得手动拆几十种byte[]更好
以前coolq就是一个string，CQCode.extract分析，但是事实证明是coolq没少因为qq更新出现消息解析bug，用了一年十几次因为各种更新出现各种空字符、整句话一个空格、CQCode解析混乱，mirai虽然source导致不能分片等以及还是不够优雅，但是从来没有因为Message系列的功能设计出现解析bug
PS：居然还有睿智用公开API改名字被投诉这么可笑的混淆视听来证明什么，不通知别人就改名字怎么都是你的错误好吧，Mirai的2.0里程碑都不知道pin了多久了 而且自从上了2.0的dev preM 几天之内连着发了十几个版，所有修改都明确写了该如何移植。更不用说基本所有软件的1.x→2.0都是解决初版设计不合理的问题的 必然出现api修改，居然还拿着那种臃肿的大厂领导驱动式项目说事
mysql 8直接引入了完全不兼容的登录协议
elastic6直接废弃type
java禁止违规的反射访问
有问题吗？
Mirai的开发者有权拒绝你使用mirai框架
git不能拉黑人真的便宜了某些人1. “Mirai的开发者有权拒绝你使用mirai框架”，你的自信从何而来，要么你给出相关许可证的依据，要么选择闭源，最终解释权归mamoe所有，要么就不要说这种毫无意义的话 2. 你的比较前提是不成立的，mysql java等每个版本都足够稳定并且易用，也就是完全可以留在旧版本不用新版本，而且相比之下，Java API改动频率是多少，占比是多少？而mirai 1.x的体验相比之下是多少？请问你的这个比较是成立的吗
对于2我只能说一点，mirai的体验是建立在腾讯服务器支持的情况下的，而此外部不可控因素是其他软件所没有的，这也就是体验下降的原因，你可以选择不用或者升级，但是请就事论事说明，这里看起来已经成为了情绪发泄的垃圾场了。