GRP C - почему `CallInvoker` должен навязывать` TRequest: class` и `TResponse: class`? - PullRequest
Новая
       6

GRP C - почему `CallInvoker` должен навязывать` TRequest: class` и `TResponse: class`?

2 голосов
/ 07 апреля 2020

Сигнатура, определенная абстрактным классом CallInvoker в Grpc.Core, накладывает ограничение типа class на TRequest и TResponse. Это предотвращает использование структур в качестве ответов для удаленного метода, например, он не работает с типом результата F # Result<'a, 'b> в качестве типа ответа, поскольку F # Result<_, _> является типом структуры.

Почему CallInvoker необходимо наложить TRequest: class и TResponse: class?

https://github.com/grpc/grpc/blob/master/src/csharp/Grpc.Core.Api/CallInvoker.cs

1 Ответ

0 голосов
/ 07 апреля 2020

Я смотрел на это в прошлом, так как хотел предложить удалить его для protobuf- net .Grp c (который отлично работает с F #, кстати); нет никакой фундаментальной причины, кроме того, что код использует часовой знак null во многих местах, чтобы иметь значение - и все эти сценарии ios должны были бы измениться, предположительно для типа кортежа, который кодирует "имеет значение "и" значение "(по существу Nullable<T>, но для любого T); и это довольно много работы.

Я открыт, чтобы попробовать, хотя; на самом деле это может быть проще, чем обходной путь, который я планировал для protobuf- net .Grp c (включающий перенос типов значений на лету).

На данный момент вам придется использовать ссылку F # типы. Например, это нормально работает с protobuf- net .Grp c: 

[<DataContract; CLIMutable>]
type MultiplyRequest =
    { [<DataMember(Order = 1)>] X : int
      [<DataMember(Order = 2)>] Y : int }

[<DataContract; CLIMutable>]
type MultiplyResult =
    { [<DataMember(Order = 1)>] Result : int }

[<ServiceContract(Name = "Hyper.Calculator")>]
type ICalculator =
    abstract MultiplyAsync : MultiplyRequest -> ValueTask<MultiplyResult>
...