Re: protocols, inheritance and polymorphism

From: Steven Bethard (steven.bethard_at_gmail.com)
Date: 11/24/04 

Date: Wed, 24 Nov 2004 06:35:20 GMT

Donn Cave wrote:
> Rather than embrace
> subtype polymorphism through inheritance, however, I see it
> as evidence that no one has figured out how to make static
> typing really work with OOP.

I'm not sure I follow your argument here. Java interfaces provide the
same sort of protocol-based typing as Python does (though of course you
have do declare interfaces everywhere to make them work this way).
Going back to my earlier Python example:

>>> def process_rules(rules):
... for rule in rules:
... print rule.name
...

the corresponding Java might look something like:

public interface Rule {
     public Object getName();
}

public class RuleProcessor {
     public void processRules(Iterable<Rule> rules){
         for (Rule rule: rules) {
             System.out.println(rule.getName())
         }
     }
}

Note that because Java is statically typed, you have to declare all the
appropriate interfaces: Iterable is in java.lang, and Rule is declared
above. In Python, the interfaces are implied by the use, and left
undeclared.

Of course, you have to declare your interfaces in a suitably generic
manner. I could have written this replacing Iterable<Rule> with
Collection<Rule> or List<Rule>, but Iterable<Rule> is the type that
makes the fewest commitments about the parameter and still allows me to
iterate over the Rule objects. Similarly, I could have written getName
to return a String, but by declaring getName with Object as a return
type, I make only the necessary commitment that getName returns a value.

The annoying thing, of course, is what you do when suddenly *one* use of
a Rule does require, say, a String result of getName:

public class OtherRuleProcessor {
     public void processRules(Iterable<Rule> rules){
         for (Rule rule: rules) {
             String[] s = rule.getName().split('\\s')
         }
     }
}

Do I now declare a new interface for this Rule and add another
implements clause to all my classes that implement the original Rule as
well? Do I make the original Rule interface less general by changing
the return type from Object to String? It can get nasty rather quickly...

Python, of course, avoids this by not declaring types. =)

Steve

Relevant Pages

  • Re: CLOS Properties Question
    ... In interfaces, you can declare methods, but you ... This mess was the result of the fact that interfaces ... > is even an OOPSLA or ECOOP paper published before the advent of Java ... > Back to the question what this all has to do with multiple inheritance: ...
    (comp.lang.lisp)
  • Re: implicit types in C# 3.0, what is the usefulness of them?
    ... > I can see where you are going here, but interfaces aren't always the answer, ... > and within method bodies I don't care that much. ... get into to declare variables with only the information which is really ... you'd either need to sacrifice some of the intent or have longer names. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Wrapping a COM DLL
    ... > static public extern uint WABOpen(ref IntPtr lppAdrBook, ref IntPtr> lppWABObject, ref IntPtr lpWABParam, uint Reserved2); ... >> Sam, ... >> Which function are you trying to declare in wab32.dll? ... >>> Do i have to declare the interfaces i need as c# interfaces? ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: MVPs: static methods in interfaces.
    ... > I have no intention of using interfaces for declaring constructors for my ... >>> static methods, even not for construction... ... and static methods cannot be polymorphic. ... >> declare an interface for a class factory and implement several factories ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: Python Oddity - print a reserved name
    ... I think that, while you're right for CPython, other Python ... Since Jython regularly accesses attributes on ... the same problem, how it's met in various interfaces to XML-RPC, COM, ... Given how pervasive this problem is, I do recall some ruminations about ...
    (comp.lang.python)