展布局設(shè)計(jì)：按生成器劃分還是按運(yùn)行時(shí)實(shí)現(xiàn)劃分？)
Protobuf Editions 中的 Feature 擴(kuò)展布局設(shè)計(jì)按生成器劃分還是按運(yùn)行時(shí)實(shí)現(xiàn)劃分【免費(fèi)下載鏈接】protobufProtocol Buffers - Googles data interchange format項(xiàng)目地址: https://gitcode.com/GitHub_Trending/pr/protobuf本文以 docs/design/editions/editions-feature-extension-layout.md 設(shè)計(jì)文檔作者 mkruskal-google、zhangskz2023-08-23 批準(zhǔn)為主體講清 Protobuf Editions 項(xiàng)目中的一個(gè)關(guān)鍵設(shè)計(jì)決策全局featuresoption 的語言級(jí)擴(kuò)展feature extensions到底應(yīng)該歸誰擁有——是歸運(yùn)行時(shí)實(shí)現(xiàn)C、upb、Java……還是歸代碼生成器protoc 插件。讀完后你將理解四個(gè)備選方案各自的利弊、最終取舍背后的權(quán)衡邏輯并能在倉庫源碼descriptor.proto 的FeatureSet定義中看到這個(gè)決策的實(shí)際落地形態(tài)。背景誰該擁有這些 Feature 擴(kuò)展What are Protobuf Editions 提出了用edition ...取代syntax ...、用可繼承的features控制代碼生成與運(yùn)行時(shí)行為的總體計(jì)劃并計(jì)劃用全局 features proto 的擴(kuò)展來讓 protobuf 團(tuán)隊(duì)之外的各方定義自己關(guān)心的特性。但當(dāng)時(shí)遺留了一個(gè)模糊點(diǎn)這些擴(kuò)展的歸屬邊界——語言language、代碼生成器code generator、運(yùn)行時(shí)實(shí)現(xiàn)runtime implementation三者相似卻不等同一種語言如 Python可能有多種運(yùn)行時(shí)實(shí)現(xiàn)純 Python、Python/C、Python/upb一種運(yùn)行時(shí)實(shí)現(xiàn)如 upb、C可能被多種語言共享Python、Rust、Ruby、PHP 都以它們?yōu)楹蠖恕Ｓ|發(fā)這次討論的具體案例是 Editions Zero Feature: utf8_validation該文檔未對(duì)外發(fā)布但后來去掉爭(zhēng)議選項(xiàng)的版本即倉庫中的 edition-zero-features.md 所討論的 UTF-8 校驗(yàn)特性。原本唯一的擴(kuò)展特性legacy_closed_enumJava/C沒有歸屬歧義而 utf8_validation 有在 Python 中proto2/proto3 下的當(dāng)前行為對(duì)三種實(shí)現(xiàn)pure Python、Python/C、Python/upb各自不同。這正是擴(kuò)展按誰劃分問題的典型壓力測(cè)試。兩個(gè)讓按運(yùn)行時(shí)實(shí)現(xiàn)劃分復(fù)雜化的現(xiàn)實(shí)原文檔在 Overview 中列出會(huì)議里討論出的兩大復(fù)雜性Polyglot多語言混用upb 或 C 運(yùn)行時(shí)在多語言場(chǎng)景下應(yīng)遵循哪套 features這一歧義其實(shí)今天就已存在——所有 proto2 字符串以及大量 proto3 字符串在跨語言傳輸時(shí)本身就是不安全的。Shared Implementations共享實(shí)現(xiàn)upb 和 C 被用作多種語言的后端。如果只有一套u(yù)pb或cpp級(jí)別的 features那么語言切換到這些共享實(shí)現(xiàn)時(shí)將更難遷移因?yàn)闆]有按語言獨(dú)立的開關(guān)。同樣這也是現(xiàn)狀——今天切換運(yùn)行時(shí)實(shí)現(xiàn)就可能帶來微妙且危險(xiǎn)的行為變化。文檔給出的結(jié)論是既然當(dāng)前只有兩種行為且其中一種無歧義不如在 edition zero 推廣過程中先擱置這個(gè)決定等收集到更多邊界案例再說同時(shí)后續(xù) edition 對(duì) features 的重新建模自由度很大所以初始實(shí)現(xiàn)應(yīng)保持最簡(jiǎn)單即下文備選方案 2。四種備選方案逐一對(duì)比方案一按運(yùn)行時(shí)實(shí)現(xiàn)劃分Runtime Implementation Features這是 Editions Zero Feature: utf8_validation 中的原始設(shè)想features 按運(yùn)行時(shí)實(shí)現(xiàn)組織。例如 Protobuf Python 用戶需要根據(jù)底層實(shí)現(xiàn)設(shè)置不同擴(kuò)展features.(pb.cpp).feature或features.(pb.upb).feature。優(yōu)點(diǎn)與 Editions 之前可表達(dá)的行為范圍最一致。缺點(diǎn)底層實(shí)現(xiàn)往往對(duì)用戶不透明用戶甚至可能不知道自己在用哪個(gè)后端而且缺乏針對(duì)語言/實(shí)現(xiàn)組合的獨(dú)立開關(guān)——例如無法獨(dú)立設(shè)置Python-on-C的行為而不動(dòng) C 本身這會(huì)加大從其他 Python 實(shí)現(xiàn)遷移的難度。方案二按代碼生成器劃分Generator Features最終采納方向features 只按生成器劃分——每個(gè) protoc 插件擁有一套自己的 features。這是團(tuán)隊(duì)在后續(xù)討論中做出的第二個(gè)決定。它與方案一非常相似但更貼合features 主要服務(wù)于 codegen的目標(biāo)。例如所有 Python 實(shí)現(xiàn)共享同一套 featuresfeatures.(pb.python).feature若某特性確實(shí)需要針對(duì)特定實(shí)現(xiàn)可以把特性名本身定向到該實(shí)現(xiàn)如features.(pb.python).upb_utf8_validation只會(huì)被 Python/upb 使用。優(yōu)點(diǎn)允許對(duì)不同目標(biāo)語言共享同一實(shí)現(xiàn)的情況做獨(dú)立控制例如 Python 的 upb 特性不會(huì)影響 PHP。缺點(diǎn)upb 需要理解自己應(yīng)該遵循哪門語言的特征而 upb 目前并不知道自己是給哪門語言服務(wù)的在行為沖突時(shí)共享實(shí)現(xiàn)的跨語言進(jìn)程內(nèi)共享如 Python-upb 與 PHP-upb 同進(jìn)程會(huì)受到限制可能還需要額外的檢查。方案三遷移到 bytesMigrate to bytes既然爭(zhēng)議圍繞 utf8 校驗(yàn)干脆不在 edition zero 引入這個(gè)開關(guān)把目前不強(qiáng)制 UTF-8 校驗(yàn)的字段全部遷移為bytes。這大概率需要一個(gè)新的代碼生成特性來把 bytes 的 getter/setter 生成為字符串 API但不存在當(dāng)前看到的歸屬歧義。文檔認(rèn)為此路不可行utf8 校驗(yàn)并不是簡(jiǎn)單的開/關(guān)二值決策它在語言之間差異很大——很多情況下 UTF-8 在部分語言中校驗(yàn)、在另一些語言中不校驗(yàn)還有 C 那種只記日志但放行非法 UTF-8的 hint 行為。文檔同時(shí)留了個(gè)口子可以在后續(xù) LSClarge-scale change中通過定向禁用所有相關(guān)語言校驗(yàn)的特性組合部分實(shí)現(xiàn)該思路。優(yōu)點(diǎn)回避問題不需要任何 upb 特性C 特性全部退化為純代碼生成特性避免在 edition zero 引入一個(gè)非常復(fù)雜的特性。缺點(diǎn)以當(dāng)前復(fù)雜度看基本做不到會(huì)有O(10M) 量級(jí)的 proto2 string 字段被盲目改為 bytes。方案四嵌套特性Nested Features允許共享的 feature set 消息upb 定義自己的 feature 消息但不把它作為全局FeatureSet的擴(kuò)展使用 upb 實(shí)現(xiàn)的語言在自己的 feature 里內(nèi)嵌一個(gè)該類型的字段實(shí)現(xiàn)更細(xì)粒度的控制。C 則既擴(kuò)展全局FeatureSet也允許作為其他語言的字段出現(xiàn)。此外可在特性校驗(yàn)階段加入檢查強(qiáng)制不可能的組合不被指定——例如在當(dāng)前實(shí)現(xiàn)下features.(pb.python).cpp必須與features.(pb.cpp)恒等因?yàn)闆]有機(jī)制區(qū)分二者。優(yōu)點(diǎn)比方案一、二更顯式。缺點(diǎn)可能過度顯式——proto 屬主被迫大量復(fù)制duplicate特性聲明。決策邏輯信息不足時(shí)選最簡(jiǎn)單的模型文檔 Overview 的結(jié)論值得單獨(dú)強(qiáng)調(diào)只有兩種行為、且其中一種無歧義此時(shí)強(qiáng)行選定按實(shí)現(xiàn)劃分還是按生成器劃分的歸屬模型風(fēng)險(xiǎn)大于收益。與其在 edition zero 就定死復(fù)雜的所有權(quán)結(jié)構(gòu)不如讓初始實(shí)現(xiàn)保持簡(jiǎn)單備選方案 2按生成器劃分把按實(shí)現(xiàn)定向留作特性命名層面如upb_utf8_validation這樣的特征名的柔性能力待推廣期積累更多邊界案例后再?zèng)Q定是否升級(jí)建模方式。這一決策也呼應(yīng)了 what-are-protobuf-editions.md 中codegen backends own the definitions of their features的總體原則——特性定義權(quán)歸各語言后端而歸屬單位是生成器。倉庫源碼印證FeatureSet擴(kuò)展聲明就是按生成器劃分設(shè)計(jì)文檔討論的抽象問題在當(dāng)前倉庫的 src/google/protobuf/descriptor.proto 中有明確的落地形態(tài)可以作為事實(shí)核對(duì)。1. 每個(gè)生成器獨(dú)占一個(gè)FeatureSet擴(kuò)展號(hào)FeatureSet消息descriptor.proto 處定義末尾用extension_range顯式登記了已分配的語言級(jí)擴(kuò)展其編號(hào)即按生成器劃分的直接證據(jù)extensions 1000 to 9994 [ declaration { number: 1000, full_name: .pb.cpp, type: .pb.CppFeatures }, declaration { number: 1001, full_name: .pb.java, type: .pb.JavaFeatures }, declaration { number: 1002, full_name: .pb.go, type: .pb.GoFeatures }, declaration { number: 1003, full_name: .pb.python, type: .pb.PythonFeatures }, declaration { number: 1004, full_name: .pb.csharp, type: .pb.CSharpFeatures }, declaration { number: 1100, full_name: .imp.impress_feature_set, type: .imp.ImpressFeatureSet }, declaration { number: 9989, full_name: .pb.java_mutable, type: .pb.JavaMutableFeatures }, declaration { number: 9990, full_name: .pb.proto1, type: .pb.Proto1Features } ]; extensions 9995 to 9999; // For internal testing extensions 10000; // for https://github.com/bufbuild/protobuf-es這段聲明印證了文檔結(jié)論的幾個(gè)要點(diǎn)沒有pb.upb、pb.cpp_impl這類按運(yùn)行時(shí)實(shí)現(xiàn)的頂層擴(kuò)展只有按語言/生成器命名的.pb.cpp、.pb.java、.pb.python……——這正是備選方案 2 的形態(tài).pb.java_mutableJavaMutableFeatures擴(kuò)展號(hào) 9989作為獨(dú)立的生成器擴(kuò)展存在而非嵌套在JavaFeatures里的字段——從源碼結(jié)構(gòu)看面向特定實(shí)現(xiàn)的變體被建模為另一個(gè)生成器級(jí)別的擴(kuò)展而不是方案 4 的嵌套特性消息保留 9995–9999 給內(nèi)部測(cè)試、10000 給第三方生成器bufbuild/protobuf-es說明這套編號(hào)空間是留給各 codegen 自持特性的開放注冊(cè)表。各生成器的特性消息定義在獨(dú)立文件中例如 src/google/protobuf/cpp_features.proto配套生成的cpp_features.pb.h/cc同目錄與extensions聲明中.pb.CppFeatures一一對(duì)應(yīng)。2. 觸發(fā)討論的utf8_validation特性長什么樣FeatureSet中的utf8_validation字段緊隨repeated_field_encoding之后定義展示了該特性在去掉爭(zhēng)議選項(xiàng)后的最終形態(tài)enum Utf8Validation { UTF8_VALIDATION_UNKNOWN 0; VERIFY 2; NONE 3; reserved 1; } optional Utf8Validation utf8_validation 4 [ retention RETENTION_RUNTIME, targets TARGET_TYPE_FIELD, targets TARGET_TYPE_FILE, feature_support { edition_introduced: EDITION_2023, }, edition_defaults { edition: EDITION_LEGACY, value: NONE }, edition_defaults { edition: EDITION_PROTO3, value: VERIFY } ];幾點(diǎn)與設(shè)計(jì)文檔的呼應(yīng)retention RETENTION_RUNTIME特性會(huì)被序列化進(jìn) descriptor 供運(yùn)行時(shí)使用即它確實(shí)橫跨 codegen 與 runtime這正是歸屬需要慎重設(shè)計(jì)的原因edition_defaults顯式區(qū)分了EDITION_LEGACYproto2 時(shí)代默認(rèn)NONE與EDITION_PROTO3默認(rèn)VERIFY把現(xiàn)狀不一致固化成按 edition 的默認(rèn)值而不是在擴(kuò)展布局上分叉reserved 1說明早期曾存在第三個(gè)枚舉值后被移除——與文檔提及的問題選項(xiàng)problematic options修訂過程一致。3. 特性解析在哪里發(fā)生從源碼結(jié)構(gòu)看倉庫中src/google/protobuf/下存在feature_resolver.h/.cc及對(duì)應(yīng)測(cè)試feature_resolver_test.cc承擔(dān)把 edition 默認(rèn)值與顯式聲明合并、完成特性繼承解析的工作FeatureSetDefaultsdescriptor.proto 處定義則攜帶每個(gè) edition 的默認(rèn)特性集合讓解析退化為找最近的匹配 edition 再做 proto 合并。特性如何被各生成器/運(yùn)行時(shí)消費(fèi)可繼續(xù)參見 docs/design/editions/editions-life-of-a-featureset.md 的完整流程描述。對(duì)實(shí)踐者的啟示寫 editions proto 時(shí)擴(kuò)展命名空間按你使用哪個(gè)生成器選擇用 C codegen 就寫features.(pb.cpp).x用 Python codegen 就寫features.(pb.python).x無論底層是不是 upb——這與文檔所有 Python 實(shí)現(xiàn)共享同一套 features的設(shè)計(jì)一致。實(shí)現(xiàn)級(jí)差異用特性名表達(dá)而不是新擴(kuò)展需要區(qū)分后端時(shí)參照features.(pb.python).upb_utf8_validation的命名思路在自己擁有的生成器擴(kuò)展內(nèi)加定向特性。理解共享實(shí)現(xiàn)的邊界以 upb/C 為后端的多種語言之間行為可能受同一實(shí)現(xiàn)、不同語言 features的沖突約束文檔方案 2 的 Cons同進(jìn)程多語言混用時(shí)值得額外驗(yàn)證序列化/校驗(yàn)行為。遷移語義依賴 edition 默認(rèn)值而非擴(kuò)展布局utf8_validation等特性的 edition 默認(rèn)值proto2→NONE、proto3→VERIFY保證了 proto2/proto3 向 editions 的機(jī)械遷移在語義上是 no-op這也是整個(gè) feature 布局設(shè)計(jì)要服務(wù)的最終目標(biāo)。延伸閱讀均在當(dāng)前倉庫內(nèi)docs/design/editions/what-are-protobuf-editions.mdEditions 總綱features/editions 的基本概念與生命周期。docs/design/editions/edition-zero-features.mdedition zero 首批特性的定義其中string_field_validationMANDATORY/HINT/NONE正是本文主題討論的前身后被utf8_validation取代。docs/design/editions/editions-life-of-a-featureset.md一個(gè) FeatureSet 從文件到生成代碼的完整旅程。docs/design/editions/README.mdeditions 設(shè)計(jì)文檔索引。src/google/protobuf/descriptor.protoFeatureSet、FeatureSetDefaults的權(quán)威定義?！久赓M(fèi)下載鏈接】protobufProtocol Buffers - Googles data interchange format項(xiàng)目地址: https://gitcode.com/GitHub_Trending/pr/protobuf創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Protobuf Editions 中的 Feature 擴(kuò)展布局設(shè)計(jì)：按生成器劃分還是按運(yùn)行時(shí)實(shí)現(xiàn)劃分？
Protobuf Editions 中的 Feature 擴(kuò)展布局設(shè)計(jì)按生成器劃分還是按運(yùn)行時(shí)實(shí)現(xiàn)劃分【免費(fèi)下載鏈接】protobufProtocol Buffers - Googles data interchange format項(xiàng)目地址: https://gitcode.com/GitHub_Trending/pr/protobuf本文以 docs/design/editions/editions-feature-extension-layout.md 設(shè)計(jì)文檔作者 mkruskal-google、zhangskz2023-08-23 批準(zhǔn)為主體講清 Protobuf Editions 項(xiàng)目中的一個(gè)關(guān)鍵設(shè)計(jì)決策全局featuresoption 的語言級(jí)擴(kuò)展feature extensions到底應(yīng)該歸誰擁有——是歸運(yùn)行時(shí)實(shí)現(xiàn)C、upb、Java……還是歸代碼生成器protoc 插件。讀完后你將理解四個(gè)備選方案各自的利弊、最終取舍背后的權(quán)衡邏輯并能在倉庫源碼descriptor.proto 的FeatureSet定義中看到這個(gè)決策的實(shí)際落地形態(tài)。背景誰該擁有這些 Feature 擴(kuò)展What are Protobuf Editions 提出了用edition ...取代syntax ...、用可繼承的features控制代碼生成與運(yùn)行時(shí)行為的總體計(jì)劃并計(jì)劃用全局 features proto 的擴(kuò)展來讓 protobuf 團(tuán)隊(duì)之外的各方定義自己關(guān)心的特性。但當(dāng)時(shí)遺留了一個(gè)模糊點(diǎn)這些擴(kuò)展的歸屬邊界——語言language、代碼生成器code generator、運(yùn)行時(shí)實(shí)現(xiàn)runtime implementation三者相似卻不等同一種語言如 Python可能有多種運(yùn)行時(shí)實(shí)現(xiàn)純 Python、Python/C、Python/upb一種運(yùn)行時(shí)實(shí)現(xiàn)如 upb、C可能被多種語言共享Python、Rust、Ruby、PHP 都以它們?yōu)楹蠖恕Ｓ|發(fā)這次討論的具體案例是 Editions Zero Feature: utf8_validation該文檔未對(duì)外發(fā)布但后來去掉爭(zhēng)議選項(xiàng)的版本即倉庫中的 edition-zero-features.md 所討論的 UTF-8 校驗(yàn)特性。原本唯一的擴(kuò)展特性legacy_closed_enumJava/C沒有歸屬歧義而 utf8_validation 有在 Python 中proto2/proto3 下的當(dāng)前行為對(duì)三種實(shí)現(xiàn)pure Python、Python/C、Python/upb各自不同。這正是擴(kuò)展按誰劃分問題的典型壓力測(cè)試。兩個(gè)讓按運(yùn)行時(shí)實(shí)現(xiàn)劃分復(fù)雜化的現(xiàn)實(shí)原文檔在 Overview 中列出會(huì)議里討論出的兩大復(fù)雜性Polyglot多語言混用upb 或 C 運(yùn)行時(shí)在多語言場(chǎng)景下應(yīng)遵循哪套 features這一歧義其實(shí)今天就已存在——所有 proto2 字符串以及大量 proto3 字符串在跨語言傳輸時(shí)本身就是不安全的。Shared Implementations共享實(shí)現(xiàn)upb 和 C 被用作多種語言的后端。如果只有一套u(yù)pb或cpp級(jí)別的 features那么語言切換到這些共享實(shí)現(xiàn)時(shí)將更難遷移因?yàn)闆]有按語言獨(dú)立的開關(guān)。同樣這也是現(xiàn)狀——今天切換運(yùn)行時(shí)實(shí)現(xiàn)就可能帶來微妙且危險(xiǎn)的行為變化。文檔給出的結(jié)論是既然當(dāng)前只有兩種行為且其中一種無歧義不如在 edition zero 推廣過程中先擱置這個(gè)決定等收集到更多邊界案例再說同時(shí)后續(xù) edition 對(duì) features 的重新建模自由度很大所以初始實(shí)現(xiàn)應(yīng)保持最簡(jiǎn)單即下文備選方案 2。四種備選方案逐一對(duì)比方案一按運(yùn)行時(shí)實(shí)現(xiàn)劃分Runtime Implementation Features這是 Editions Zero Feature: utf8_validation 中的原始設(shè)想features 按運(yùn)行時(shí)實(shí)現(xiàn)組織。例如 Protobuf Python 用戶需要根據(jù)底層實(shí)現(xiàn)設(shè)置不同擴(kuò)展features.(pb.cpp).feature或features.(pb.upb).feature。優(yōu)點(diǎn)與 Editions 之前可表達(dá)的行為范圍最一致。缺點(diǎn)底層實(shí)現(xiàn)往往對(duì)用戶不透明用戶甚至可能不知道自己在用哪個(gè)后端而且缺乏針對(duì)語言/實(shí)現(xiàn)組合的獨(dú)立開關(guān)——例如無法獨(dú)立設(shè)置Python-on-C的行為而不動(dòng) C 本身這會(huì)加大從其他 Python 實(shí)現(xiàn)遷移的難度。方案二按代碼生成器劃分Generator Features最終采納方向features 只按生成器劃分——每個(gè) protoc 插件擁有一套自己的 features。這是團(tuán)隊(duì)在后續(xù)討論中做出的第二個(gè)決定。它與方案一非常相似但更貼合features 主要服務(wù)于 codegen的目標(biāo)。例如所有 Python 實(shí)現(xiàn)共享同一套 featuresfeatures.(pb.python).feature若某特性確實(shí)需要針對(duì)特定實(shí)現(xiàn)可以把特性名本身定向到該實(shí)現(xiàn)如features.(pb.python).upb_utf8_validation只會(huì)被 Python/upb 使用。優(yōu)點(diǎn)允許對(duì)不同目標(biāo)語言共享同一實(shí)現(xiàn)的情況做獨(dú)立控制例如 Python 的 upb 特性不會(huì)影響 PHP。缺點(diǎn)upb 需要理解自己應(yīng)該遵循哪門語言的特征而 upb 目前并不知道自己是給哪門語言服務(wù)的在行為沖突時(shí)共享實(shí)現(xiàn)的跨語言進(jìn)程內(nèi)共享如 Python-upb 與 PHP-upb 同進(jìn)程會(huì)受到限制可能還需要額外的檢查。方案三遷移到 bytesMigrate to bytes既然爭(zhēng)議圍繞 utf8 校驗(yàn)干脆不在 edition zero 引入這個(gè)開關(guān)把目前不強(qiáng)制 UTF-8 校驗(yàn)的字段全部遷移為bytes。這大概率需要一個(gè)新的代碼生成特性來把 bytes 的 getter/setter 生成為字符串 API但不存在當(dāng)前看到的歸屬歧義。文檔認(rèn)為此路不可行utf8 校驗(yàn)并不是簡(jiǎn)單的開/關(guān)二值決策它在語言之間差異很大——很多情況下 UTF-8 在部分語言中校驗(yàn)、在另一些語言中不校驗(yàn)還有 C 那種只記日志但放行非法 UTF-8的 hint 行為。文檔同時(shí)留了個(gè)口子可以在后續(xù) LSClarge-scale change中通過定向禁用所有相關(guān)語言校驗(yàn)的特性組合部分實(shí)現(xiàn)該思路。優(yōu)點(diǎn)回避問題不需要任何 upb 特性C 特性全部退化為純代碼生成特性避免在 edition zero 引入一個(gè)非常復(fù)雜的特性。缺點(diǎn)以當(dāng)前復(fù)雜度看基本做不到會(huì)有O(10M) 量級(jí)的 proto2 string 字段被盲目改為 bytes。方案四嵌套特性Nested Features允許共享的 feature set 消息upb 定義自己的 feature 消息但不把它作為全局FeatureSet的擴(kuò)展使用 upb 實(shí)現(xiàn)的語言在自己的 feature 里內(nèi)嵌一個(gè)該類型的字段實(shí)現(xiàn)更細(xì)粒度的控制。C 則既擴(kuò)展全局FeatureSet也允許作為其他語言的字段出現(xiàn)。此外可在特性校驗(yàn)階段加入檢查強(qiáng)制不可能的組合不被指定——例如在當(dāng)前實(shí)現(xiàn)下features.(pb.python).cpp必須與features.(pb.cpp)恒等因?yàn)闆]有機(jī)制區(qū)分二者。優(yōu)點(diǎn)比方案一、二更顯式。缺點(diǎn)可能過度顯式——proto 屬主被迫大量復(fù)制duplicate特性聲明。決策邏輯信息不足時(shí)選最簡(jiǎn)單的模型文檔 Overview 的結(jié)論值得單獨(dú)強(qiáng)調(diào)只有兩種行為、且其中一種無歧義此時(shí)強(qiáng)行選定按實(shí)現(xiàn)劃分還是按生成器劃分的歸屬模型風(fēng)險(xiǎn)大于收益。與其在 edition zero 就定死復(fù)雜的所有權(quán)結(jié)構(gòu)不如讓初始實(shí)現(xiàn)保持簡(jiǎn)單備選方案 2按生成器劃分把按實(shí)現(xiàn)定向留作特性命名層面如upb_utf8_validation這樣的特征名的柔性能力待推廣期積累更多邊界案例后再?zèng)Q定是否升級(jí)建模方式。這一決策也呼應(yīng)了 what-are-protobuf-editions.md 中codegen backends own the definitions of their features的總體原則——特性定義權(quán)歸各語言后端而歸屬單位是生成器。倉庫源碼印證FeatureSet擴(kuò)展聲明就是按生成器劃分設(shè)計(jì)文檔討論的抽象問題在當(dāng)前倉庫的 src/google/protobuf/descriptor.proto 中有明確的落地形態(tài)可以作為事實(shí)核對(duì)。1. 每個(gè)生成器獨(dú)占一個(gè)FeatureSet擴(kuò)展號(hào)FeatureSet消息descriptor.proto 處定義末尾用extension_range顯式登記了已分配的語言級(jí)擴(kuò)展其編號(hào)即按生成器劃分的直接證據(jù)extensions 1000 to 9994 [ declaration { number: 1000, full_name: .pb.cpp, type: .pb.CppFeatures }, declaration { number: 1001, full_name: .pb.java, type: .pb.JavaFeatures }, declaration { number: 1002, full_name: .pb.go, type: .pb.GoFeatures }, declaration { number: 1003, full_name: .pb.python, type: .pb.PythonFeatures }, declaration { number: 1004, full_name: .pb.csharp, type: .pb.CSharpFeatures }, declaration { number: 1100, full_name: .imp.impress_feature_set, type: .imp.ImpressFeatureSet }, declaration { number: 9989, full_name: .pb.java_mutable, type: .pb.JavaMutableFeatures }, declaration { number: 9990, full_name: .pb.proto1, type: .pb.Proto1Features } ]; extensions 9995 to 9999; // For internal testing extensions 10000; // for https://github.com/bufbuild/protobuf-es這段聲明印證了文檔結(jié)論的幾個(gè)要點(diǎn)沒有pb.upb、pb.cpp_impl這類按運(yùn)行時(shí)實(shí)現(xiàn)的頂層擴(kuò)展只有按語言/生成器命名的.pb.cpp、.pb.java、.pb.python……——這正是備選方案 2 的形態(tài).pb.java_mutableJavaMutableFeatures擴(kuò)展號(hào) 9989作為獨(dú)立的生成器擴(kuò)展存在而非嵌套在JavaFeatures里的字段——從源碼結(jié)構(gòu)看面向特定實(shí)現(xiàn)的變體被建模為另一個(gè)生成器級(jí)別的擴(kuò)展而不是方案 4 的嵌套特性消息保留 9995–9999 給內(nèi)部測(cè)試、10000 給第三方生成器bufbuild/protobuf-es說明這套編號(hào)空間是留給各 codegen 自持特性的開放注冊(cè)表。各生成器的特性消息定義在獨(dú)立文件中例如 src/google/protobuf/cpp_features.proto配套生成的cpp_features.pb.h/cc同目錄與extensions聲明中.pb.CppFeatures一一對(duì)應(yīng)。2. 觸發(fā)討論的utf8_validation特性長什么樣FeatureSet中的utf8_validation字段緊隨repeated_field_encoding之后定義展示了該特性在去掉爭(zhēng)議選項(xiàng)后的最終形態(tài)enum Utf8Validation { UTF8_VALIDATION_UNKNOWN 0; VERIFY 2; NONE 3; reserved 1; } optional Utf8Validation utf8_validation 4 [ retention RETENTION_RUNTIME, targets TARGET_TYPE_FIELD, targets TARGET_TYPE_FILE, feature_support { edition_introduced: EDITION_2023, }, edition_defaults { edition: EDITION_LEGACY, value: NONE }, edition_defaults { edition: EDITION_PROTO3, value: VERIFY } ];幾點(diǎn)與設(shè)計(jì)文檔的呼應(yīng)retention RETENTION_RUNTIME特性會(huì)被序列化進(jìn) descriptor 供運(yùn)行時(shí)使用即它確實(shí)橫跨 codegen 與 runtime這正是歸屬需要慎重設(shè)計(jì)的原因edition_defaults顯式區(qū)分了EDITION_LEGACYproto2 時(shí)代默認(rèn)NONE與EDITION_PROTO3默認(rèn)VERIFY把現(xiàn)狀不一致固化成按 edition 的默認(rèn)值而不是在擴(kuò)展布局上分叉reserved 1說明早期曾存在第三個(gè)枚舉值后被移除——與文檔提及的問題選項(xiàng)problematic options修訂過程一致。3. 特性解析在哪里發(fā)生從源碼結(jié)構(gòu)看倉庫中src/google/protobuf/下存在feature_resolver.h/.cc及對(duì)應(yīng)測(cè)試feature_resolver_test.cc承擔(dān)把 edition 默認(rèn)值與顯式聲明合并、完成特性繼承解析的工作FeatureSetDefaultsdescriptor.proto 處定義則攜帶每個(gè) edition 的默認(rèn)特性集合讓解析退化為找最近的匹配 edition 再做 proto 合并。特性如何被各生成器/運(yùn)行時(shí)消費(fèi)可繼續(xù)參見 docs/design/editions/editions-life-of-a-featureset.md 的完整流程描述。對(duì)實(shí)踐者的啟示寫 editions proto 時(shí)擴(kuò)展命名空間按你使用哪個(gè)生成器選擇用 C codegen 就寫features.(pb.cpp).x用 Python codegen 就寫features.(pb.python).x無論底層是不是 upb——這與文檔所有 Python 實(shí)現(xiàn)共享同一套 features的設(shè)計(jì)一致。實(shí)現(xiàn)級(jí)差異用特性名表達(dá)而不是新擴(kuò)展需要區(qū)分后端時(shí)參照features.(pb.python).upb_utf8_validation的命名思路在自己擁有的生成器擴(kuò)展內(nèi)加定向特性。理解共享實(shí)現(xiàn)的邊界以 upb/C 為后端的多種語言之間行為可能受同一實(shí)現(xiàn)、不同語言 features的沖突約束文檔方案 2 的 Cons同進(jìn)程多語言混用時(shí)值得額外驗(yàn)證序列化/校驗(yàn)行為。遷移語義依賴 edition 默認(rèn)值而非擴(kuò)展布局utf8_validation等特性的 edition 默認(rèn)值proto2→NONE、proto3→VERIFY保證了 proto2/proto3 向 editions 的機(jī)械遷移在語義上是 no-op這也是整個(gè) feature 布局設(shè)計(jì)要服務(wù)的最終目標(biāo)。延伸閱讀均在當(dāng)前倉庫內(nèi)docs/design/editions/what-are-protobuf-editions.mdEditions 總綱features/editions 的基本概念與生命周期。docs/design/editions/edition-zero-features.mdedition zero 首批特性的定義其中string_field_validationMANDATORY/HINT/NONE正是本文主題討論的前身后被utf8_validation取代。docs/design/editions/editions-life-of-a-featureset.md一個(gè) FeatureSet 從文件到生成代碼的完整旅程。docs/design/editions/README.mdeditions 設(shè)計(jì)文檔索引。src/google/protobuf/descriptor.protoFeatureSet、FeatureSetDefaults的權(quán)威定義?！久赓M(fèi)下載鏈接】protobufProtocol Buffers - Googles data interchange format項(xiàng)目地址: https://gitcode.com/GitHub_Trending/pr/protobuf創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考