4 ms·
> But don’t make LSP itself a first class concept. Why not? I’m interested in any concrete reasons why doing so would be a bad idea, why you should maintain in
by chrismorgan 5y ago
> But don’t make LSP itself a first class concept.
Why not? I’m interested in any concrete reasons why doing so would be a bad idea, why you should maintain independent extension points and bind LSP to them, rather than providing LSP-shaped extension points, as it were.
- matklad 5y agoSeveral things: _First_, a general clean architecture considerations -- protocol is "view", it shouldn't infect the model. _Second_, LSP is a way to consume semantic info, but there might be others. A different protocol might come along, or you might want to embed the server as a library somewhere. _Third_, LSP is language agnostic, so, to implement LSP, you'd have to dumb-down internal rich language specific representation to a language agnostic one. The system will be more evolvable if such dumbing down happens near the edge of the system. _Fourth_, LSP really just stretches the surface of whats possible. Language servers should push the boundaries of whats possible to both deliver a better UX for a specific language as well as to pressure the protocol itself to implement more advanced features. The design guideline we use in rust-analyzer is that we are building not for LSP/VS Code, but for a hypothetical, rust-specific perfect IDE whose frontend is capable of doing anything we want.