ptkwt / shell1.aracnet.com (Phil Tomson) writes:
[snip]
> ClassA.isomorphic?(ClassB) #returns true if there is a 1:1 correspondence
>                            #between methods in ClassA and ClassB
> ClassA.containsMethods?(ClassB) #returns true if ClassA defines all of the   
>                            # same methods that ClassB has defined (but
>                            # ClassA could define methods not defined in
>                            # ClassB

I don't think I would ever use the isomorphic? method. I very, very rarely
want to answer the question "do these two object implement the exact same
methods and nothing else?" I'm most interested in seeing if an object
responds to a handful of particular methods. That's mostly because I only
need to know what an object can do when it is an argument passed to a
method. It's almost a question with a local scope: "can you do a, b, and
c?"

As for containsMethods?, that seems more useful especially if you think of
ClassB as a Java interface (defining method signatures but no behavior). In
Ruby there are Modules, but they usually implement behavior. ClassB would
have to be an abstract Module that is potentially the superclass of some
other concrete modules. The question I really want answered, again, is
"does this object respond to methods a, b, and c?" What's needed is
something that represents the unique collection of methods a, b, and c;
it's not a Module or a class, though.

> Also, what about this idea of set operations on Classes (where we look at 
> classes and modules as sets of methods)?  Would it buy us anything?

Interesting. If methods a, b, and c were a subset of a larger clump, but
I'm inside my method and only care if an object responds to a, b, and c,
then you could ask it "do you respond to this subset of the larger clump of
methods?"

Jim
-- 
Jim Menard, jimm / io.com, http://www.io.com/~jimm/
"An object at rest cannot be stopped!"
    -- The Evil Midnight Bomber What Bombs At Midnight