[Python-3000] pep 3124 plans

[Greg Ewing]

Phillip J. Eby wrote:
> At 12:54 PM 7/24/2007 +1200, Greg Ewing wrote:
>> When adding an overload to a GF, what methodology can I
>> follow to ensure that my overload doesn't interact in an
>> unfortunate way with another one somewhere else, perhaps
>> one not written by me?
> 
> What methodology can you follow that ensures that same thing when 
> overriding a method in a subclass?

It's dead simple -- my method always wins.

This is true even in the presence of multiple inheritance.
Problems only arise there if I use super() to make an
inherited method call (so I don't do that) or if other
people multiply inherit from me -- in which case it's
their problem, not mine.

> Okay, well I guess the above statements all put you squarely in the "OO 
> is too scary" category,

Certainly not -- I don't find OO scary at all. I wouldn't
say that I find GFs "scary" either, only that I would use
them cautiously and sparingly. I don't agree that there is
no difference between the traditional OO model and GFs.
With GFs there is less static structure that you can rely
on.

>> And what if the program doesn't exist yet, because I'm
>> still thinking about how to write it? Or it exists but
>> isn't yet in a state where it can be run successfully?
> 
> I don't understand what you're asking, here.

Don't you think it's important to be able to reason about
the way a program will behave while you're in the process
of designing it? If you haven't written runnable code yet,
you can't run it to get a list of method overrides.

> I was under the impression that 
> under certain circumstances, if one object is "more specific" than the 
> other (i.e., one is an instance of a subclass of the other's type), then 
> that one gets first say.

You may be right. But the fact remains that the method called
will be a method of one class or the other -- it can't be some
function defined in an arbitrary place.

--
Greg