Re: Inheritance and Polymorhpism (getting back to the point)

From: Costin Cozianu (c_cozianu_at_hotmail.com)
Date: 11/15/03 

Date: Sat, 15 Nov 2003 08:26:22 -0800

Uncle Bob (Robert C. Martin) wrote:

> igouy@yahoo.com (Isaac Gouy) might (or might not) have written this on
> (or about) 14 Nov 2003 09:41:43 -0800, :
>
>
>>Wouldn't that also apply to languages such as Smalltalk, Python, and
>>Ruby? To call a method polymorphically, all the methods you want to
>>use need to share a common *implicit* abstract type?
>
>
> No, objects in those language simply respond to messages. If two
> completely unrelated objects both respond to message 'm', then you can
> pass either of those objects to any function that sends message 'm';
>
>

Now, have you noticed that he mentioned *implicit* ? Of course not.

That means in dynamically typed languages there is simply an interface
which is informally specifed, typically in the documentatiom

For example, if you have a method:

sort(array)

The documentation specifies that the array should be an array of objects
that support comparison, either through "<" operator or through a
specific method compareTo(otherObject) or whatever is the protocol. Now
this is an important abstraction: *the interfacece between two modules*,
and it is so fundamental to software engineering, that it has been
discussed for over three decades (yet many OO people manage to forget it).

However, in dynamically typed languages this is demoted to an *informal*
abstraction which makes things harder not easier. You may save a few
keystrokes to spear yourself a dclaration

   MyClass implements Comparable

But that's the only ilusory advantage you can get. When other guy comes
to read that code, or even when you read months later you want to see at
a glance what are the contracts for that class to abide by, and that
information is simply not there or it is there in a peculiar form (in
comments), but not as a first class language abstraction.

The problem is so peculiar, that it turns out in practice that in
languages like Python, they inherit on purpose from a base class
defining the interface, because they don't have Java interfaces. And
when they do that they already sacrificed another useful inheritance
relationship.

So this proves you raised a Red Herring against statically typed
languages. The inability to have interfaces as first class abstraction
*coupled* with the need to use the rigidity (as you say) of inheritance
to specify the interface between modules may very well turn out to be:

one of the fundamental language design problems for DTL.

Here's the documentation from Python standard library. As you see for a
nontrivial interface they just had to declare base classes, or else
there's no manageable and efficient way that somebody will implement the
protocol:

-------
The SAX API defines four kinds of handlers: content handlers, DTD
handlers, error handlers, and entity resolvers. Applications normally
only need to implement those interfaces whose events they are interested
in; they can implement the interfaces in a single object or in multiple
objects. Handler implementations should inherit from the base classes
provided in the module xml.sax, so that all methods get default
implementations.

class ContentHandler
     This is the main callback interface in SAX, and the one most
important to applications. The order of events in this interface mirrors
the order of the information in the document.

class DTDHandler
     Handle DTD events.

     This interface specifies only those DTD events required for basic
parsing (unparsed entities and attributes).

class EntityResolver
     Basic interface for resolving entities. If you create an object
implementing this interface, then register the object with your Parser,
the parser will call the method in your object to resolve all external
entities.

class ErrorHandler
     Interface used by the parser to present error and warning messages
to the application. The methods of this object control whether errors
are immediately converted to exceptions or are handled in some other way. 

----
QED

Relevant Pages

  • Re: New to Python: Features
    ... check out greenlets or Stackless Python. ... There is a TCL interface. ... We don't do messaging syntax. ... Depends on how experienced you are with those languages. ...
    (comp.lang.python)
  • Re: object system...
    ... In a typed system you can separate implementation from the interface ... C/I is also unable to effectively facilitate some non-C/I languages, ... Performance of hash tables is less predictable, ...
    (comp.object)
  • Re: A taxonomy of types
    ... With this explanation OO (as seen in statically typed OO languages ... The static type defines the interface for the variables, ... objects (in the Seed7 philosophy really everything is an object), ... OCaml, which applies to lists of ints, lists of strings, etc.) and, say, ...
    (comp.lang.misc)
  • Re: Interaction between subclass and UI
    ... dialog or control for each subclass. ... You create an interface that is used to construct related objects. ... my ILanguageGenerator heirarchy has three concrete objects: ... the user has a menu that shows the different languages that they can ...
    (comp.software.patterns)
  • Re: we have a "this" keyword, but what if... we also had "component" keyword??
    ... We can easily mimic this behavior in functional languages by ... > OO languages do this automatically, for every instance method the ... > interface and a protected interface to its decendants. ... > class instance to the inner class, however what is not provided is the ...
    (comp.object)