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
Take #transform. Forget what “class” it belongs to. What does it do?
For the sake of this dialog lets say it does this:
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”.
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?