Re: Polymorphism, Isomorphism

In article <[e-mail]>, Jim Menard  <[e-mail]> wrote:
>[e-mail] (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?" 

Perhaps you're right.  I also think that the method shouldn't be called 
'isomorphic?' because we might be stepping on a method name that might be 
included in a graph library, for example.  

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

Hmmm.... So you're proposing something like:

ClassA.containsMethods(:foo, :bar, :baz)

or something similar.

Here's another crazy idea: What if you could do logical operations on 
classes (given the premise that we look at Classes as sets of methods - 
perhaps not a perfect analogy, but I'm thinking this way for the sake of 
brainstorming).

class ClassA
def foo
....
end

def bar
....
end
end

class ClassB
def baz
....
end
def bar
....
end
end

listOfCommonMethods = ClassA.and(ClassB)

listOfCommonMethods = [:bar]

unionOfMethods = ClassA.or(ClassB)
unionOfMethods = [:foo, :bar, :baz]

Or, and now this is getting pretty crazy, what if you get an instance of 
an object which represented the union - this would be something very close 
to multiple-inheritance or maybe mixin (it would probably share all of 
the problems of MI - like if a certain method exists in both 'parent' 
classes which one do you take?).  Or even an instance of a class which 
represents the intersection of two classes - not sure what that would be akin 
to - and again you have the problem of determining which method from 
which class to choose, so perhaps it would be best to stick to lists of 
method names as the result of these logic operations.

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

It does seem like something like that would be useful in some cases.

I'm not sure any of these (set) theoretical musings will lead to anything 
practical (I suspect not), but it's interesting to ponder them.

Phil