[Python-3000] pep 3124 plans (original) (raw)

Jan Grant jan.grant at bristol.ac.uk
Wed Jul 25 11:03:08 CEST 2007

On Mon, 23 Jul 2007, Talin wrote:

Phillip J. Eby wrote:

> I just don't see that the things Greg is describing aren't equally > applicable to traditional methods. I wasn't going to get into this, but - since you asked :) The short form of the argument is that being able to overload any function as a generic function retroactively changes the implicit contract of what that function is.

I don't think this is really true in programs written with good taste - ie, it's no more true than in the OO case.

In the OO case, one might consider the class of an object to be closely associated with a contract describing its intended semantics (its type). If a function takes a parameter and is written expecting that it is passed an argument of type B (for come class B), then by subclassing B into a derived class, D, you ought to be able to pass an instance of D to the same function which should be able to use it, regardless.

That's what subclassing means: if D is a subclass of B, then all instances of D should behave appropriately and according to the intended semantics of B when used as a B.

Of course, it's perfectly possible to abuse subclassing to acquire implementation rather than the type/contract, but well-written* OO programs at least draw a clear distinction between those uses if they do it at all.

So, when you look at an OO program that makes extensive use of subclassing, you typically have a notion of what method calls should do at a broad semantic level because that notion is part of the contract implicit in the type.

Exactly the same is true with GFs. Yes, you can overload "add()" to mean "subtract" or "remove a random file" or "close all database connections" in certain cases. That's painfully flying in the face of the intended semantics of the function you're overloading; so, don't do that.

Cheers, jan

-- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ Spreadsheet through network. Oh yeah.

More information about the Python-3000 mailing list