本頁面由 Cloud Translation API 翻譯而成。

RFC-0044：可擴充方法引數

RFC-0044：可延伸方法引數
狀態	已遭拒
領域	FIDL
說明	我們建議 FIDL 程式庫作者在需要擴充性時，使用資料表而非結構，但方法引數是編碼成結構體。這意味著，以資料表為基礎建構可延伸的方法引數。
作者	vardhan@google.com ianloic@google.com
提交日期 (年-月-日)	2019-04-08

編輯此 RFC

編輯 RFC 中繼資料

拒絕原因

已由 RFC-0050: 語法修改淘汰。

摘要

我們建議 FIDL 程式庫作者在下列情況下使用資料表而非結構體：雖然方法引數會編碼為結構體，因此需要擴充性。這個提議以資料表為基礎建構可延伸的方法引數。

提振精神

缺乏可擴充方法引數的語法，因此不建議程式庫的作者使用避免使用資料表讓方法引數可擴充這樣一來，您只要在語法，因此在設計時通訊協定

Modular 團隊正在設計需要同時維護 ABI 的通訊協定提升相容性，並可擴展性，因為他們掌握新的要求和發展設計。他們考慮按照資料表定義方法代表系統宣告的非強制性要求

設計

本提案將延伸 FIDL 原文語言，並影響應用程式語言繫結。

FIDL 語法

其提議擴充方法和事件要求及回應的語法將資料表新增至引數結構。

以此通訊協定為例：

protocol Example {
    Foo(int32 arg1, { 1: string arg2, 2: bool arg3 }) -> ({});
};

宣告一個方法，其中包含一個必要引數、兩個選用引數、可延伸要求及可延伸的回應等同於宣告：

table ExampleFooRequestExtension {
    1: string arg2;
    2: bool arg3;
};
table ExampleFooResponseExtension {
};
protocol Example {
    Foo(int32 arg1, ExampleFooRequestExtension extension)
        -> (ExampleFooResponseExtension extension);
}

IR

目前的 IR 版本能以回溯相容的方式擴充。可延伸，且具有下列名稱的資料表： {Protocol}{Method}RequestExtension、{Protocol}{Method}ResponseExtension 或包含 {Protocol}{Method}EventExtension。[ExtensionArgument] 屬性設定於這些產生的資料表，讓繫結產生器處理或他們願意提供內容

未來的事件處理 (IR) 可能會將此構想提升到更一流的結構。未來 IR 應該具備更靈活的宣告命名方式，才能讓語言可以做出更好的命名擴充功能資料表，舉例來說，C++ 在通訊協定定義類別中建立巢狀結構

繫結

繫結不需要特殊支援可擴充方法引數。現有執行個體繫結產生器只會將產生的資料表當做引數新增至方法。

C++

以 C++ 繫結為例，假如上述通訊協定沒有任何變更，大致如下：

class ExampleFooRequestExtension;
class ExampleFooResponseExtension;
class Example {
  using FooCallback = fit::function<void(ExampleFooResponseExtension)>;
  virtual void Foo(int32_t arg1,
                   ExampleFooRequestExtension extension,
                   FooCallback callback) = 0;
};

繫結這項通訊協定的另一種方式為：

class Example {
  using FooCallback = fit::function<void()>;
  virtual void Foo(int32_t arg1,
                   FooCallback callback,
                   std::optional<std::string> arg2 = std::optional<std::string>(),
                   std::optional<bool> arg3 = std::optional<bool>()) = 0;
};

這會與方法的宣告方式更相符，但會將回呼引數。

飛鏢

Dart 支援選用且具名引數，因此能正確對應 FIDL 與語法類似Dart 缺少元組或變異數的未來支援仍處於限制階段。繫結介面可能如下所示：

abstract class Example {
  Future<ExampleFooResponseExtension> foo(int arg1, {String arg2, bool arg3});
}

透過這個語法新增額外擴充功能引數時，會保留來源相容性。

荒漠油廠

未定

查看

未定

簡易 C

簡易 C 繫結不支援表格，因此這項功能不相容看似有益或無害的 AI 用途也可能夾帶問題或相關風險

執行策略

第一步是在 fidlc 中新增對新語法的支援更新參考資料和教學說明文件

接下來，我們會對 Dart 繫結新增支援明顯的人體工學效益也顯而易見

人體工學

允許演變 FIDL 通訊協定相當重要。目前變更方法的引數會導致 ABI 和 API 故障變更。變造的方法會導入新方法每項變更的名稱，且會繼續支援舊方法仍是呼叫端，或將資料表做為引數加入，並加入新引數表格。本提案允許以更能體現人體工學它會保留方法定義中定義的引數，也能在說明文件註解中找到相關資訊

選用引數的概念在許多程式設計語言中都很常見。不會對圖書館作者來說是個令人驚訝的概念

對資料表中明確序數的需求會導致擴充引數不一致但最好能和資料表保持一致而不是導入具有雜湊序數的新資料表式結構。

說明文件和範例

做為 FIDL 語言的擴充功能，提供 FIDL 參考資料和教學課程說明文件。

回溯相容性

現有的 FIDL 程式庫不受此次異動影響。

本提案大幅改善了圖書館作者維護 ABI 的能力長期支援相容介面

關於原始碼相容性的限制仍然待定，我們會透過我們計劃如何繫結至支援的語言

成效

資料表編碼及解碼的成本比結構體高，因此效能更高重要通訊協定必須謹慎使用此功能

安全性

沒有影響

測試

測試應新增至 fidlc。危險 ID 測試應測試使用危險 ID 做為選用引數

缺點、替代方案和未知

替代方案

我們可以根據方法或個別通訊協定，從結構體轉換為資料表。三甚至可以將預設從結構體改為資料表這種做法也較不具彈性通常只有請求或回應會預期已延長。通常是部分引數 (例如 Modular 的情況 id) 長期下來會保持穩定，其他則不然。

與其使用資料表並針對每個擴充引數要求序數可以定義類似資料表的資料結構，對名稱進行雜湊處理有些奇蹟這麼做可簡化原文語言的語法，但新增編碼器、解碼器和語言繫結的複雜度

我們可以使用版本化方法。而不是深入探討這個選項。

開放式問題

我們應決定在 C++、Rust 和 Go 中繫結的方式。

是否應新增引數以打斷原始碼相容性？

既有藝術品和參考資料

Protobuf 會從通訊協定方法宣告訊息脫行。

Flatbuffer 和 Capn proto 版本管理。