interface reuse over code reuse

Henry Spencer <henry@zoo.toronto.edu> wrote:
>Indeed, there are a significant number of people who think that once you
>strip away the OOH (Object-Oriented Hype), being able to reuse
>*interfaces* is much more important than being able to reuse code. If the
>interface is held constant, you can build up a library of different
>implementations of the underlying abstraction to satisfy different sets of
>tradeoffs.


>From my recent experience with using classes in Python, I would agree with
that statement. Python is an OO language that is "objects all the way
down", but the builtin objects are not part of the class system. Thus,
you can use (multiple) inheritance with user defined classes, but you
can't inherit methods from builtin objects like files, integers, lists,
strings, etc. What you can do, though, is to emulate the interface of
builtin objects by defining the appropriate methods in your class.


For example, if you define methods for all of the standard numeric
operations, you can create new numeric types. If you define methods for
len, getitem, getslice you have something that behaves like a sequence,
and if you add setitem and setslice it becomes a mutable sequence.


So I've had occasion to use both inheritance and a sort of abstract data
typing in Python. Inheritance is *nice* - it avoids a lot of cutting and
pasting in the editor - but the big gain (IMHO) seems to be from reusing
the interface - not necessarily the code.


[ And isn't that one of the secrets of the power of Unix - that it
    makes a lot of different things act just like a sequential file? ]




The only problems appear to be:
(1) Keeping that consistency when you aren't using inheritance to
        enforce it. [ I've been arguing against some inconsistencies
        on the python-list, for example, that
        array.write( file, count ) is different enough from
        [file|pipe|socket].write( count ) that it would be better
        called by a different name. ]
(2) In a dynamic/interpreted language like Python, you have to pretty
        much give up on (dynamic) type checking as overly restrictive.
        You don't really want to know if two objects share a common base
        class - what you really want to know is if it is going to behave
        the way you expect a (number|sequence|file|some-other-type) to
        behave. Avoiding type-checking seems to allow you to discover
        unexpected treats, for example, that it's possible to create
        complex numbers composed of rational parts. [ There was a long
        thread on comp.object about heterogeneous containers that
        verged into this area just around the time I we were discussing
        the pros and cons of typechecking on the python-list. I had been
        proposing adding standard boolean methods like "isnumeric" and
        "isasequence" to make it possible to check the type of arguments
        without being overly exclusive, but I have given up on that for
        now. It seems if you are going to trust another class programmer
        to have defined those booleans to behave properly, you might as
        well go all the way and trust that if the class has a method
        defined for __add__, then you should (provisionally) assume that
        it works the way you expect it to work. One counter example to
        isnumeric was a date class. It might support offsets to a date,
        or subtracting two dates, but not multiplying or dividing, So
        should it claim to be numeric ? ]


Sorry about the rambling nature towards the end. I should have gone
home a couple of hours ago. I'm going to print out David Keppel's
paper and go home now.




- Steve Majewski (804-982-0831) <sdm7g@Virginia.EDU>
- UVA Department of Molecular Physiology and Biological Physics
--

Return to the comp.compilers page.
Search the comp.compilers archives again.