3 ms·
It’s cool to see code in an interpreted language being edited at the repl. Ruby’s style of building everything at runtime using the language itself has always
by heads 3y ago
It’s cool to see code in an interpreted language being edited at the repl. Ruby’s style of building everything at runtime using the language itself has always felt delightfully consistent, but also very hard to reason about with static analysis — the usually tool for helping developers in their IDEa and LSP clients.
Far nicer to just execute the program and put a breakpoint at the cursor…
COLORS.each{ |c|
define_sheep_class(c)
}
sheep1 = Sheep::Bl|
This feels like the only way my editor stands a chance of completing this to Sheep::Black. Is this how Ruby IDE support works (e.g. in the JetBrains product.)
- djur 3y agoIt's too dangerous to execute the code to provide completion support. IDE support has to rely on static analysis.
- heads 3y agoI suppose you could run the unit test suite?
- dpassens 3y agoNo, you couldn't. If running the code is too dangerous, then so is running the unit test suite. You'd have to prove that it doesn't do anything observable, like accidentally deleting your home directory, or, if the code is actively malicious, uploading your SSH key somewhere. And if you can do that, you probably also have enough information to provide good completion without running the code.
- vidarh 3y agoYou can get quite far by symbolic evaluation of a fairly small subset of Ruby - the most common patterns used use a fairly small number of methods. Frankly I think not going further is a good thing in that it'll discourage people from going unnecessarily far with the dynamic features.