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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4