4 ms·

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 anyth

by Eridrus 10y ago

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.

hitr 10y ago
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)
- avita1 10y ago
  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).
  - deleted 10y ago
    [deleted]
- Eridrus 10y ago
  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.
  - euyyn 10y ago
    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.
  - deleted 10y ago
    [deleted]
riffraff 10y ago
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)
- Eridrus 10y ago
  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.

by Eridrus 10y ago

hitr 10y ago

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)

avita1 10y ago
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).
- deleted 10y ago
  [deleted]
Eridrus 10y ago
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.
- euyyn 10y ago
  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.
- deleted 10y ago
  [deleted]

riffraff 10y ago

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)

Eridrus 10y ago
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.