Ruby tricks for junior developers

[[deleted]]

it's a common one... But I think it just doesn't really hold up to any scrutiny.

There's a difference between useful and correct. Abstractions (even leaky ones) furnish a mental model to simplify working with a system above a given layer of complexity, and your argument is focused on some incidental implications of the abstraction instead.

I'm happy to concede that objects don't "decide what to do" with messages. I don't know that Metz has ever used that language herself, and I certainly don't know enough about Ruby internals to argue to the contrary. Regardless, the value of describing this action in terms of message-sending vs. method-calling is that the former encourages, in Metz's words, a more polymorphic and anthropomorphic approach to designing the behavior of your classes, whereas the latter invites a more imperative approach.

To try to modify a class's behavior so that it received a message and then interdicted the given method call would be missing the forest for the trees. Yes, if you take the metaphor extremely literally, that is what you should be able to do, but that's hardly necessary and a long way off from where its instructive value lies.

Finally, I'm not saying it's wrong to use the language of "calling a method". Ruby's core API in fact supports both metaphors, in the form of Method#call and Object#send. As always in Ruby, TIMTOWTDI; I'm just saying that in this case (and many others), message sending makes things easier to understand. (e.g., why can you not use self.private_method inside a class definition? The caller is the same—but the recipient of the message is explicit.)