You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To improve LSP servers' interop with LSP clients when implemented with StreamJsonRpc, consider an option on JsonRpc that allows server methods to receive all named arguments via one deserialized type specified as the server method's first/only parameter.
This could replace the one JToken parameter from LSP server methods with the anticipated type per the LSP spec that is already provided by an LSP protocol library. So instead of a server method boilerplate looking like this:
This option allows the LSP library to add properties to the CompletionParams type (for example) without method signatures being updated. The downside is this is a clear departure from the expected behavior of JSON-RPC behavior, which states that named arguments should be matched to method parameters. But we're not really losing anything there since we're already just packing it all as a JToken.
To improve LSP servers' interop with LSP clients when implemented with StreamJsonRpc, consider an option on
JsonRpc
that allows server methods to receive all named arguments via one deserialized type specified as the server method's first/only parameter.This could replace the one
JToken
parameter from LSP server methods with the anticipated type per the LSP spec that is already provided by an LSP protocol library. So instead of a server method boilerplate looking like this:It could look like this:
The text was updated successfully, but these errors were encountered: