Skip to content

Conversation

@davidanthoff
Copy link
Member

@davidanthoff davidanthoff commented May 15, 2020

This is very much WIP. Ready for review. See julia-vscode/LanguageServer.jl#701 for an example of how to use this.

There are two goals: 1) add a more static API on top of what is there already (i.e. incorporate the ideas from https://github.com/julia-vscode/LanguageServer.jl/blob/master/src/jsonrpc.jl into here) and 2) add a layer that can dispatch messages to callback handler functions.

@codecov
Copy link

codecov bot commented May 16, 2020

Codecov Report

❗ No coverage uploaded for pull request base (master@ff52a6f). Click here to learn what that means.
The diff coverage is n/a.

Impacted file tree graph

@@           Coverage Diff            @@
##             master      #4   +/-   ##
========================================
  Coverage          ?   0.85%           
========================================
  Files             ?       3           
  Lines             ?     117           
  Branches          ?       0           
========================================
  Hits              ?       1           
  Misses            ?     116           
  Partials          ?       0           
Flag Coverage Δ
#unittests 0.85% <0.00%> (?)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ff52a6f...8f8ef3a. Read the comment docs.

@davidanthoff davidanthoff requested a review from ZacLN May 17, 2020 15:28
@davidanthoff davidanthoff added the enhancement New feature or request label May 17, 2020
@davidanthoff davidanthoff marked this pull request as ready for review May 17, 2020 15:28
src/typed.jl Outdated

struct RequestType{TPARAM,TR} <: AbstractMessageType
method::String
dict2param::Function
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this mean the RequestType holds the methods for converting to and from the Dict that represents the JSON format? Would this then require a significant refactoring of the LSP (i.e. all the Dict->DataType converters built by @dict_readable share the name of DataType

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was my initial idea, but I removed that. The current design is such that every RequestType just links the method name with a type for the parameters and a type for the return value.

For the conversion from Dict to type it just passes the dict to the constructor of the type, and for the conversion from type to JSON it just relies on whatever mechanism there is in JSON (I think). I think that means it should all work with the existing design for conversions, right? That was the goal, in any case ;)

@davidanthoff
Copy link
Member Author

@ZacLN I think this is ready to be merged?

@davidanthoff davidanthoff merged commit 4d8f2ae into master May 20, 2020
@davidanthoff davidanthoff deleted the dispatcher branch May 20, 2020 08:24
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement New feature or request

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants