[Python-3000] pep 3124 plans
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
* 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.
More information about the Python-3000
mailing list