PEP 245
Alex Shindich
shindich at itginc.com
Thu Apr 5 12:46:37 EDT 2001
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.
More information about the Python-list
mailing list