On 11 Mar 2006, at 22:58, Logan Capaldo wrote:

>
> On Mar 11, 2006, at 5:23 PM, kwatch wrote:
>
>> Thanks Austin,
>>
>> Austin Ziegler wrote:
>>>
>>> In the last four years of using Ruby, I thought I needed abstract
>>> methods in the first few months. Then I learned what value  
>>> Modules as
>>> mixins gave me.
>>>
>>> I do not believe that this is a common enough need that it needs  
>>> to be
>>> in the core of Ruby.
>>
>> Well, I think that abstract method is more basic than 'singleton.rb'
>> or 'delegate.rb' which are bundled in Ruby.
>>
>>
>>> I encourage you to do what others have done with this sort of
>>> mismatched feature and make a library that implements it and make it
>>> available for use. Your pure-Ruby implementation looks more than
>>> sufficient.
>>
>> I'll make it library and register it to RubyForge.
>>
>>
>>> More than that, though, I encourage you to rethink why you need
>>> abstract methods. Most of the time this is because you're  
>>> thinking in
>>> terms of C++ or Java inheritance, when Ruby's mixins are both more
>>> powerful and applicable in most cases where you would define a
>>> hierarchy that has abstract methods.
>>
>> In my opinion, 'mixin' is one thing and 'abstract method' is another.
>> Mixin doesn't cover abstract method.
>>
>> The following is an example of visitor pattern.
>> It shows that mixin doesn't cover abstract method.
>>
>> ----------
>> module Visitor
>>   def visit_foo(acceptor)  # abstract method
>>     mesg = "#{self.class.name}#visit_foo() is not implemented."
>>     raise NotImplementedError.new(mesg)
>>   end
>>
>>   def visit_bar(acceptor)  # abstract method
>>     mesg = "#{self.class.name}#visit_foo() is not implemented."
>>     raise NotImplementedError.new(mesg)
>>   end
>> end
>>
>> class MyVisitor
>>   include Visitor     # mix-in
>>
>>   def visit_foo(acceptor)
>>     puts "visit_foo() called."
>>   end
>>
>>   def visit_bar(acceptor)
>>     puts "visit_bar() called."
>>   end
>> end
>>
>> class Foo
>>   def accept(visitor)
>>     visitor.visit_foo(self)
>>   end
>> end
>>
>> class Bar
>>   def accept(visitor)
>>     visitor.visit_bar(self)
>>   end
>> end
>> ----------
>>
>> Ruby's mix-in is more sophisticated solution than interface of Java
>> or multiple inheritance of C++, I think.
>> But mix-in and abstract method are different thing.
>>
>> --
>> regards,
>> kwatch
>>
>>
>
> I think you're over engineering. Let's consider the Enumerable  
> module for instance. It has an "abstract" method of sorts, each.
>
> class A
>    include Enumerable
> end
>
> a = A.new
> a.map { |x| x + 1 }
>
> Oh look, this code already raises an exception, a NoMethodError.  
> Now I know that to include Enumerable I have to have an each method.

:) True, yes. For documentation though, it's nice to know that you're  
supposed to implement something. You could point that out with a  
comment of course. But a comment wouldn't be picked up by some  
hypothetical parser that's looking at your code (not just to execute  
it) and trying to deduce things about it... :) I think I like the  
idea of a declaration for an abstract methods because it makes clear  
your intention.