38 ms·
"param" isn't a variable unless you defined it in the current method - it lacks a sigil so if it's a variable it must be a local one. So it's more likely to be
by vidarh 3y ago
"param" isn't a variable unless you defined it in the current method - it lacks a sigil so if it's a variable it must be a local one. So it's more likely to be a method, and so you can usually find where it was defined with self.method(:param).source_location (or use pry or irb, or rdbg, and drop to a debugger session and you have easy access to nicer methods). If you don't want to run a tool like pry or rdbg, then sure, Ruby will be painful for you, just the same way as refusing the use the best available tooling will make working with most languages.
As for disliking Rails, join the club, plenty of Ruby users dislike Rails too.
- jupp0r 3y agoSorry for the contrived example. My whole point was that you have to use the debugger in order to read code. I'm not unwilling to do it, it's just extremely unproductive vs reading code that's understandable without having to reverse engineer it.
- vidarh 3y agoIf running a tool like pry (which is not a traditional debugger, for that we have rdbg) slows you down, then that is a tooling problem. Instead of just reading the code, you can read it and explore the API live. To me that's usually far faster beyond a couple of pages worth of code, because you see how the code actually works rather than how you imagine it should.