PEP 245

[Alex Shindich]

A collogue of mine who is a Perl diehard, sent me his thoughts on the
subject of adding interface support to languages like Perl and Python. His
is not a Python expert, but has an extensive expertise in Perl.
I think that most of you will find his comments interesting.

Regards,

Alex Shindich

-----Original Message-----
Sent: Thursday, April 05, 2001 9:28 AM
To: Alex Shindich
Subject: Re: PEP 245


On Wed, Apr 04, 2001 at 08:32:58PM -0700, Alex Shindich wrote:
> I guess I should just give up my fight against PEP 245...

Ok, seriously now.  Here are the questions I asked yesterday.


    (1) I need to give some background before I can ask the first
    question.  Bear with me.  There are two ways to extend a language:
    Extend the "core" language or extend its standard library.
    Languages like Java tend to require more core extensions than Perl
    or Python do.  For example, I doubt it would have been possible to
    add interfaces to Java just by extending the Java library.  At least
    a few core extensions were required.

    On the other hand, it would be easy to write a Perl module,
    "interface", and do this:

        # IProgrammer.pm
        package IProgrammer;
        use interface qw(
            code writeRequirements design drinkCoffee
        );
        1;

        # Alex.pm
        package Alex;
        use base qw(IProgrammer);       # Alex IS-A IProgrammer
        # ...
        1;

    Notice that my hypothetical interface extension is packaged
    as a module.  I didn't need to hack Perl's interpreter to add an
    "interface" keyword.

    In fact, most of Perl OO is done just this way.

    So my question is:  If you need "interface", why not add it as a set
    of modules instead of changing the Python core?

    (2) My second question is more fundamental:  Why do we want a
    Java-like interface anyway?  As I said yesterday, Java's interface
    is much too restrictive.  It prevents me from checking pre- and
    post-conditions.  Why spread a bad idea?

    (3) My third question is also fundamental:  In Perl or Python, who
    cares whether you implement an entire interface?  If all I want
    today is to do "x," all I care about is whether your module can do
    "x." Now, "x" may usually be packaged with operations "y" and "z"
    and I may well have a base class that offers all three.  Indeed,
    that base class may well be the equivalent of an IXyz interface.
    But I don't need "y" or "z" today.  I know that Perl programmers
    make use of Perl's flexibility in this regard.  You can ask any
    module whether it does "x" without caring whether it does all the
    other things it "should" do.

    Come to think of it, the same applies to C++.  No, not to
    inheritance, to templates.  When you instantiate a C++ class
    template, the compiler is supposed to instantiate only the member
    functions you need.  Those member functions are the only part of the
    interface that you care about.  Indeed, people sometimes write
    classes with member functions that cannot all compile at the same
    time.  (E.g., some of them might work only with pointers, others
    only with classes.)  It's up to the client to pick the subset of
    member functions that he needs.