docs: §18 八个角度的实现后复核(v1.5) - #314
Merged
Merged
Conversation
§6 那张表是设计时写的,实现之后没回头修订。逐条回看,八条里有四条被推翻或需要
重述——把它们留在原样比不写更糟,下一个人会照着一张已经不成立的表做决定。
推翻两条:
架构 「新增仓数量 = 0」→ 实际新建五个。错在把「进已有 fork」当成可选的组织
方式;它不是,一个 fork 仓对应一个上游一个版本。
兼容性 「全部新增,不动任何已发布包」→ 动了三个。错在把「新增」等同于「无风
险」:DISCOVERY 加一行会让现有提供方自动继承它;新增一个消费者会暴露
compat.freetype 的源码列表缺口。
重述四条:
稳定性 风险不在难写的代码里,在写完之后没人检查的断言里。实现期代价最高的
三类失败都不在设计时的风险清单上。
跨平台 真正咬人的不是 CPU 架构,是编译器与标准库(static inline 实例化、
<sstream> 传递包含),两个都只有 llvm 腿抓得到。
一致性 「生成物签进仓」被推翻——改由 build.mcpp 构建期产出,由此消掉了
「数据与代码不一致」这个状态本身。
无感升级 同版本重发换了三种形态出现,结论是 tag 指向历史、资产承载分发。
成立两条:优雅(feature 机制把「替消费者选」变成「让消费者选」)、用户体验
(模块层不只是换写法,它是放置适配代码的位置)。
只改 .agents/docs/。
§18 的整个理由是「下一个人会照着 §6 那张表做决定」——那 §6 自己就必须说它 已经被推翻,否则读者根本走不到 §18。加一列结论标记(❌/⚠/✅)+ 小节号, 以及一句「不要单独引用本节」。
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
§6 多角度评估那张表是设计时写的,实现之后没回头修订。逐条回看,八条里有四条被推翻或需要重述 —— 把它们留在原样比不写更糟,因为下一个人会照着一张已经不成立的表做决定。推翻两条
架构 —— 设计时写「不新建仓,新增仓数量 = 0」,实际新建五个。
错在把「进已有 fork」当成可选的组织方式。它不是:一个 fork 仓对应一个上游、一个版本。wayland-protocols 有自己的版本号和发布周期,塞进
mcpplibs/wayland等于让两个上游共用一个 tag。兼容性 —— 设计时写「全部是新增条目,不动任何已发布包」,实际动了三个:
compat.freetype(#311)、xim:mesa(xim#733)、graphics.consumer_envs(xim#735)。错在把「新增」等同于「无风险」。新增一个条目会改变现有条目的行为 —— DISCOVERY 表加一行,不传
only的调用点就自动继承了它;新增一个消费者,compat.freetype的源码列表缺口就暴露了。重述四条
.gitignorestatic inline取地址强制实例化(lld 不经传递 DT_NEEDED 解析)、<sstream>传递包含(libc++ 没有),两个都只有 llvm 腿抓得到build.mcpp构建期产出,由此消掉了「数据与代码不一致」这个状态本身(name,version)不重解压、删 tag 让 release 掉成草稿成立两条,而且被加强
优雅 —— 设计时的「只做无 X11 的库」成立,而 cairo 的 feature 机制是更好的形态:不是替消费者选,而是让消费者选。差别是真实的 —— 前者意味着要 X11 的人没得用。
用户体验 ——
import那条成立,且多出一层:模块层是放置适配代码的位置。libdisplay-info 七个公共头一个extern "C"都没有,模块把包装做在里面,消费者不用管。八条里两条推翻、四条重述、两条成立。设计时的判断有一半没扛过实现 —— 而这正是「验证要更新到文档」的意义:留下的应该是被证伪之后的那一版。
只改
.agents/docs/。