From: transfire@...
Date: 2006-07-24T08:09:58+09:00
Subject: I'll have the duck!

I promised myself I'd shut-up for awhile, maybe I still should, but I
just couldn't help myself with this one...

Today I wrote

    data = data.transform

but I meant to write

    data = transform(data)

While I knew data would be hash, I certainly didn't want to write a new
Hash method just for this --you reserve extensions for really general
reusable stuff, right? Besides I wanted to remain open to duck typing
and hence any hash-like object.

That's when it hit me. We haven't yet taken the full duck type plunge.
We've just strapped a quasi-duck onto an old oop type dog. We're still
defining our methods base on types, not duck types.  But what would
defining on duck type mean intead? As it turns out it measn defining on
method dependencies.

Take #transform. Forget what "class" it belongs to. What does it do?
For the sake of this dialog lets say it does this:

  def transform
    data.to_a
  end

Simple. Now, if I want to call #transform on data, all it needs to do
is repond_to #to_a. It need not matter at all what class it is. So
imagine if you will, that instead of "classes" and "methods", we could
define "ducks" and "quacks".

  duck to_a
    quack transform
       self.to_a
    end
  end

Now anything that responded to #to_a could use #transform. I'm not sure
how far this can be taken. Can classes be undone altogegther? But in
anycase, it seems very cool, and I wonder what kind of overall effect
it could have on coding?

T.