> I can see a name and match that to an import and match that to a package. I mi...

Lio · on Nov 12, 2021

If you ever wonder where something comes from and you can't get your editor/IDE to tell you, you can always try asking the runtime.

Drop a debugger statement in above the code in question, then at the prompt turn the method into a Method object using something like:

  bar_method = foo.method(:bar)

and then

  bar_method.source_location

Once you have a Method object you can pass it around as a stand alone function, rebind it or call too.

#source_location only works for methods defined in ruby itself i.e. not C or Java but it's still a handy tool on big ruby projects.

Most of the time I just use ctags to navigate new codebases but we also have things like Solargraph via LSP too.

nitrogen · on Nov 12, 2021

Drop a debugger statement in above the code in question

If you're using Pry as your REPL, you can use Pry's ls and show-source commands to get more of the info you want at once, with less typing. It's basically calling the Ruby introspection methods for you.

    ls foo
    show-source -d foo.bar

vidarh · on Nov 12, 2021

"pry" is absolutely essential. I often prototype my code with a simple helper script that gives me a function to reload the relevant code, and just "live" in the pry prompt to explore the code as I add it.

It's the closest thing you get in Ruby to a Smalltalk environment.

mypalmike · on Nov 12, 2021

> you can always try asking the runtime

90% of the time, I'm trying to read code in a very local context and understand it, which involves being able to trace an identifier to its source. I don't want to run it. Maybe I can't run it (it's a rarely executed path, the runtime env is complex, someone emailed me a copy of a source file, etc.).

Language developers, be like Python. Be like Java. Be boring and explicit.

Spivak · on Nov 13, 2021

You don’t deserve the downvotes here. Real life Ruby is so magic, opaque, and spooky action at a distance to a degree that makes maintenance on a large codebase functionally impossible for anyone who is not actively working on that codebase.

I know literally zero Go; don’t even think I could write a hello world from memory. But I can and have submitted non-trivial patches to Go codebases to fix bugs, add features, and even a few race conditions.

friedman23 · on Nov 12, 2021

Having to use a debugger to determine the types of variables at runtime is just so terrible and backwards. I've had to debug massive python projects that have used monkey patching in the framework and it was terrible. This thread is actually causing me pain and making me relive horrible bugs i've had to fix. Reading about auto loading and having to use a debugger to inspect types is just so fucking bad.

rubyist5eva · on Nov 12, 2021

I use Rubymine and can cmd+click on anything and it shows me exactly where it came from. Been developing in rails for a decade and the auto loading has bitten me at most 5 times.

handrous · on Nov 12, 2021

Onboarding to all but the most perfectly-written-and-maintained Rails codebase is pure hell, for exactly that reason. I've done lots of Rails in the past, but sworn it off after enough such experiences.

[EDIT] Which sucks, because I really like Ruby.

gls2ro · on Nov 13, 2021

Here it is important to notice that Rails is like a superset of Ruby. Rails = Ruby + conventions + helpers.

So if you want to always be aware where things come from choose Sinatra, Padrino or Hanami.

joelbluminator · on Nov 12, 2021

Are you using a good IDE? With Rubymine (which indexes all of your gems) this is a much less big a deal.