From: Logan Capaldo <logancapaldo@...>
Date: 2006-03-13T00:25:33+09:00
Subject: Re: [RCR] abstract method in Ruby

--Apple-Mail-1-661157955
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed


On Mar 12, 2006, at 2:38 AM, kwatch wrote:

> I think it is very important that the code itself is descriptive.
> The following code doesn't describe that method each() is abstract.

I think then we have a difference of opinion of the meaning and usage  
of abstract methods.
I am of the opinion that they exist to enforce stronger typing,  
especially at compile time. It's a solution to the problem of having  
a class we're the implementation of a given method is given to a  
child class but all methods available to a class must be known at  
compile time. It's especially helpful when the abstract method must  
return something, and there is no sane default.

class A {
    int someAbstractMethod( ) {
          // If I don't have abstract methods, what should I return?
          // whatever I return, it won't be correct and it won't  
force child classes
          // to implement me
    }
}


OTOH in ruby since it's dynamically typed, the compiler won't  
complain about undefined methods until they actually get called (if  
they are still undefined)

eg
class A {
     someOtherMethod( ) {
            x = someAbstractMethod( ); // forces child classes to  
implement it simply by calling it
     }
}

Now if you want to have an argument about static vs. dynamic typing  
that's one thing. You say that it's important that code be  
descriptive. You also say that documentation is insufficient. I  
disagree, and say no code is possibly descriptive enough. Whether  
attempting to call a method
that relies on an "abstract" method raises a NoMethodError or a  
NotImplementedError the result is the same. The programmer must go  
read the documentation (or possibly the calling code) to figure out  
what was expected of him.

Basically, I feel abstract methods are a primarily feature of static  
typing and help ensure the correctness of your code. But they are a  
typing feature and the error message you get from them isn't any more  
descriptive than "function max expected int, got string"

Tangentially related to this, I find your Visitor example a little  
weak, since your Visitor module provides no methods of its own.  
Modules are not Java interfaces, and the only reason to write  
"include Visitor" in your code is to say
# this class implements the methods required to visit other objects
I think you've turned the idea of descriptive code into a degenerate  
case of ALL this code does is describe. It has no functional purpose.  
It's like using no-ops to spell out documentation in morse-code :)  
(admittedly, that analogy is a bit ridiculous).

Feel free to ignore the previous paragraph by saying something along  
the lines of "Well of course a real visitor module would have  
additional methods, it was just an example." :)
--Apple-Mail-1-661157955--