Hacker News Reader

Comment by Eridrus | Hacker News Reader

I'm on the fence about this, standardization let's people pool resources to provide common functionality, but it also ossifies the interface so that doing anything not supported by the interface becomes harder than before.

The first thing that pops into my head is that for languages with interprocedural type inference, I really want my IDE to show me what types it has inferred, but this is outside the spec and not even applicable to all languages.

View on HN

With this,a new language can have an IDE integration done easily which can cover say 95% features. Some language specific feature may be obviously left out but getting a minimum viable integration to any supported IDE is a good thing.May be when this protocol evolves,it can give extension to the protocols to cover the other 5% features(or may be it is already there)

Are there any examples of extensible protocols like this in the wild? I'm asking because the only such protocol that seems to get mentioned on HN is XMPP (and always with groans).

Heh. We'll see. Writing the glue code is not what makes writing language analysis hard. This is clearly a move to make the lives of IDE writers easier, rather than those who would be writing the analysis code.

But it'd make your analysis code work for multiple IDEs and editors instead of having to learn about each's peculiarities. One less thing to worry about is always good.

wouldn't inferred types fit into the "Diagnostic" interface? There are both "info" and "hint" levels which seem appropriate.

(I don't disagree with your general point, just curious about this specific example)

Sort of; the hover interface helps, but I would prefer it if the IDE showed it as if it was written there explicitly, not just when you hover over it.

Which requires explicit UI work, which this protocol won't support.

Reply on news.ycombinator.com