3 ms·
Given Ruby culture of monkey patching, not always. Besides, many people dev Ruby with a lightweight text editor, like text mate, that can't introspect code.
by BiteCode_dev 2y ago
Given Ruby culture of monkey patching, not always.
Besides, many people dev Ruby with a lightweight text editor, like text mate, that can't introspect code.
- mp1mp2mp3 2y ago> ...culture of monkey patching... I haven't seen more than a handful of PRs with monkey-patching in the last decade and even then they are accompanied by long-winded explanations/apologies and plans for removal ASAP (eg monkey-patching an up streamed fix that hasn't been released yet). Also, ruby classes/methods can tell you all about themselves, so if you haven't got ruby-lsp up and running (and even if you do) you can always open a repl (on its own, in the server process, or in a test process) and ask the interpreter about your method. It's pretty great! It's definitely the case that the editor's ability to understand code via static analysis is limited compared to other languages, but it's not like we ruby devs are navigating in the dark.
- goatlover 2y agoCan't the text editor open a shell where you can run the repl to do the inspection?
- throw10920 2y agoIf you monkey patch, you get what you paid for - and an annotation at the call site or definition wouldn't help anyway! If not, then we should be able to use the type annotations that are being added to also indicate async-ness. If people decide to code Ruby "blind" (without a smart IDE), then that's their choice. There's no reason why someone using an IDE should have to pay for their decisions. We don't force people to manually and redundantly add names and types of parameters to call sites - it makes equally little sense to do the same for async. If someone decides to use a dumb IDE, then they can read the docs, exactly the same as they do for function parameters.