Re: method names in 1.9

On Nov 11, 2007 5:01 AM, Matthew Boeh <[e-mail]> wrote:
>
> On Sun, Nov 11, 2007 at 05:50:18PM +0900, Trans wrote:

> > But is this distiction usable in nay way? Whe do they not coccur
> > together. I'm just curious. I've heard this before, and while I
> > basically understand, I don;t see how it plays out in actual Ruby
> > practice.

>
> The first thing that comes to mind is method_missing.
>
>   ; class Q
>   ;   def method_missing(meth, *args)
>   ;     "zzz"
>   ;   end
>   ; end
>   ; a = Q.new
>   ; a.send(:arbitrary_message)
>   # => "zzz"
>   ; a.method(:arbitrary_message)
>   NameError: undefined method `arbitrary_message' for class `Q'
>           from (irb):8:in `method'
>           from (irb):8
>           from :0
>
> Now, whether the distinction is actually significant in any practical sense is
> a different issue. In my experience, it's confusing at first, especially to
> programmers from a procedural background, but it ultimately results in a more
> sophisticated understanding of the object-oriented paradigm. It isn't
> necessarily Ruby's place to fit itself to the task of pedagogy, but I
> personally value the distinction between sending a message to an object
> (Object#send) and invoking one of its methods (Object#method -> Method#call).

Understanding this distinction is crucial to understanding why Ruby
isn't like C++ or Ruby.

Ruby, like Smalltalk, and Self, are languages which exemplify what
Ralph Johnson calls the "mystical view" of object-orientation, as
opposed the the "software engineering view" taken by C++/Java/Dylan..
http://www.cincomsmalltalk.com/userblogs/ralph/blogView?showComments=true&printTitle=Erlang,_the_next_Java&entry=3364027251

Quoting Ralph: "The mystical view is that an OO system is one that is
built out of objects that communicate by sending messages to each
other, and computation is the messages flying from object to object.
The software engineering view is that an OO system is one that
supports data abstraction, polymorphism by late-binding of function
calls, and inheritance."

A key difference between these two views is that in the mystical view,
the message name (i.e. the name used to represent a requested
operation) is defined independently of any type/class hierarchy.
Notice that Ralph's description of the mystical view makes no mention
of methods or functions. Although in most mystical languages most
messages result in the execution of a method with the name of the
message, this isn't always true, e.g. when a message is handled via
method_missing.

The mystical view puts a wall of encapsulation between sender and
responder which isn't there in the software engineering view.  The
sender names a request, and the receiver responds.  The sender has no
knowledge of (and therefore no dependency on) just how the receiver
decides to implement the response.

Adherents of the software engineering view tend to think, whether
consciously or unconsciously, in terms of late-bound function calls.
The model is that the caller knows how to find a particular 'virtual
function' and then invokes it.

It's a subtle shift in viewpoint but it's crucial.


-- 
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/