For that, there's

    object.method(:name).source
    object.method(:name).source_location

but frankly this is still thinking in a rigid mindset that suits other languages better. Ruby isn't just "dynamic dispatch"; a typical metaprogramming technique handles all incoming calls without named methods, or by dynamically writing the code.

To put it bluntly, assuming there's a method on the other side of your message, is practically the antithesis of Ruby.

It's similar to the category error that leads folks to conflating type with class, and writing type checkers that look for class signatures.

While freeing to write, that is horrifying to inherit.

That isn’t code you write in an application. The topic was how to find a method’s handler, this is how it’s done in the REPL.

Or if you mean, dynamically instantiated methods, those are found throughout Ruby and its ecosystem, and the reason it isn’t horrifying is that the language has terrific support at the REPL for developers needing reflection.

Yeah this is pretty much why I decided I didn't want to write Ruby anymore. You may be right that this is the philosophy of the language, but if it introduces a speed bump or cognitive overhead when trying to understand what a snippet of code is doing (and I contend that "there might not even be a method there responding to your message" is a speed bump), then it's not a good thing, even if it's clever and somehow ideologically pure and interesting. I can appreciate programming languages as art pieces, but when I'm at work I want them to just be a tool.

The best features about this bridge are that it's made out of soap bubbles and it doesn't necessarily span the river at any given time. This flexibility is wonderful.

That is not a good metaphor for anything, really: no-one was enlightened; at best some reddit-grade snark was conveyed.

I worked with Ruby for two years. The metaphor is apt when considering software development as an engineering discipline. It was certainly not meant as snark. You disagree, that's fine.

Not really sure what you think I disagree with, since the metaphor is so vague and wishy-washy it could apply to anything from theology to stamp collecting, but it sounds like trying to conflate late binding with some manner of bad coding style.

Well, since I have been privileged to work with several really great Ruby teams over the last couple of decades, whose large and well-structured code uses metaprogramming techniques yet remains easy to follow & comprehend (and debug and extend), and who remain splendidly productive to boot, I can say, if this bunch of guesses at the intended meaning of that "soap bubble" metaphor hold water, then yeah, I disagree.

Conversely, shitty code can be (and is) written in explicit import and early-bound languages. The enterprise world, for example, is riddled with massive hairballs of brittle, unmaintainable, boilerplate-heavy Java.

All of which only goes to show that people, not the programming language, are the problem.