views:

307

answers:

3

If I say

x.hello()

In Java, object x is "calling" the method it contains.

In Ruby, object x is "receiving" the method it contains.

Is this just different terminology for expressing the same idea or is there a fundamental difference in ideology here?

Coming from Java I find Ruby's "receiver" idea quite baffling. Perhaps someone could explain this in relation to Java?

+5  A: 

Someone correct me if I'm wrong, but I don't think you can apply these terms to Java. Ruby comes from Smalltalk, which uses messages (not methods) to communicate between objects. Technically, when you do myObj.to_s in Ruby, you are sending the to_s message to myObj and it is acting upon that message accordingly. With that model, myObj is indeed the receiver of this message and the class that owns the line where the message was sent is the sender.

In Java, this doesn't exist. You have objects that you call methods on. There are no senders and receivers. You had it right when you said there is a fundamental difference in ideology.

Marc W
My thinking would have been consistent with yours so I wish whoever voted you down would have explained why.
lorz
It's just terminology: in a method `this` is a pointer the receiver, you can retrieve the sender (or caller) using things like `sun.reflect.Reflection.getCallerClass` and a method call is_a message send.
Aaron Maenpaa
Yeah... I agree than an explanation would be nice, too.
Marc W
y the downvote??
Perpetualcoder
@Aaron: it is just terminology, yes, but it's a different mindset and a different way to think about how they work. Java and Ruby are fundamentally different in more ways than method-invoking vs. message-passing, and these differences must be understood in whatever way possible in order to be a good, language-agnostic developer.
Marc W
+9  A: 

In your example x is not calling hello(). Whatever object contains that snippet is "calling" (i.e., it's the "caller"). In Java, x can be referred to as the receiver; it is receiving the call to the hello() method.

erickson
+4  A: 

The difference is more than terminology. In Java, the VM determines whether a given object "accepts" the message that you're trying to send (i.e., the method you're trying to call). If the object's type space doesn't define that method, an exception is thrown and the message is never delivered.

In Ruby, the message is always delivered. The object may find a method that matches it, or it may not, and in the latter case it may throw an exception, or it may not. Rails is built on this fundamental difference. It's one of the reasons why there isn't a DB-backed web app framework as useful as Rails on the Java platform yet (though some are getting close).

Sarah Mei
Why is this feature such a benefit in Rails?
lorz
One example is ORM in ActiveRecord. You have an ActiveRecord object that represents a database row, say a book. It has no methods on it that correspond to your column, but you can do things like @book.isbn. @book gets the message, notices there is no isbn method, and then looks in the associated database table for a column with that name. If it finds a column with the right name, it returns the value. To the caller, it looks like a method call that returned a value.
Sarah Mei
I see. So method_missing is responsible for that ability to shift gears when there's no method found at runtime.
lorz