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

:) I was thinking things like this a while ago, and a clever friend
pointed me to predicate classes (see google). The idea with them is that
you define a predicate such as "supports the method 'each'". You could
call this predicate Enumerable. The predicate is a declaration of your
interface requirements. You can then add methods to this Enumerable
predicate class, such as min, max, inject, etc. From then, anything that
is Enumerable will also support the things you put in to Enumerable.
Pretty cool.

I liked the idea, anyway. I like it because I think it would make it
easier to take things that you've already got, things that someone has
given to you perhaps, and say new things about them based on the fact
that they've pretty much got the interface you're looking for (if they
don't quite have the right interface, you can use predicate classes to
give them the additional "glue" that they need).

I also like it because I don't think that there's anything especially
fundamental about classes. With predicate classes, all you're really
saying is that "if I've got something that can do x and y, then I know
that I can equally validly think of it as something that can do z".

[I should point out here that I don't imagine Predicate Classes are "the
answer"; I'm just pointing to them as being interesting.]

Class hierarchies almost always seem arbitrary and task oriented to me.
That works well when you've a particular task in mind, but I think it
falls over when the task changes, or when you're more interested in the
information in some objects, rather than what they are currently being
used for.

I also think they're an impediment to being agile because you're
building up a hierarchy that may not exist. Sure, you can refactor, and
perhaps you've got automated tools that do that, but you shouldn't need
to. You, and any part of your program or someone else's, ought to be
able to look at some existing objects in any way they choose. You should
be able to say anything you like about your particular way of looking at
those things.

While I like Ruby a great deal (and I really mean that: it's made
programming fun again, for me), I don't think contemporary OO is all
that. Something that's wonderful about Ruby though, is that I think it's
got every chance of being the platform in which people find that out,
and find a better way.

On the other hand, I could be wrong, in which case Ruby's already there :)

Cheers,
  Benjohn