[Python-3000] pep 3124 plans

[Jan Grant]

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

* Excuse the unavoidably emotive terminology like "well-written". I know 
there are other views - I'm just arguing this one.

-- 
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.