Logan Capaldo wrote:
> Now if you want to have an argument about static vs. dynamic typing
> that's one thing.

I have no intention to argue about dynamic vs. static.
My opinion is that the concept 'abstract method' is useful
in both dynamic and static language.
Static language may have much merits of abstract method
than dynamic language, but the concept of abstract method
give merits to dynamic language, too.


> 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.

What you say is right.  I agree with your opinion.
My point is that program code should be descriptive and
it should be prime documentation than comment or api doc.
Abstract method helps this.


> 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"

I separate 'abstract method' and 'typing'. They are different thing, I
think.
I have no intention to bring strong typing into Ruby.
The merits of abstract method is not only typing.
Please take account of reading code, as well as writing or executing
code.
Descriptive code help those who reading the program code.


> 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

Hmm, how about the template-method pattern?

  module Template
    def setup
      # default: nothing
    end

    def teardown
      # default: nothing
    end

    abstract_method :main

    def execute
      setup()
      main()
      teardown()
    end
  end

  def Foo
    include Template

    def main
      # do something
    end

    def setup
      # ...
    end
  end

  obj = Foo.new
  obj.execute


> 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).

Again, please take account of 'readability' of program code.
Higher readability brings higher maintainancability and lower cost.
The aim of abstract method is not to provide concrete functionality.

--
regards,
kwatch