Method objects question

[Donn Cave]

Quoth bmcd at es.co.nz (Ben Caradoc-Davies):
| On 23 Nov 1999 17:01:53 GMT, Donn Cave <donn at u.washington.edu> wrote:
|> It doesn't seem to matter where a function is defined, only the scope
|> where it's found.  The normal and most convenient way to get a function
|> into the class name space is certainly to define it there, but any other
|> way will serve as well - it doesn't matter if you define it outside the
|> class, or inside.
|> How could we justify anything different, in a dynamic "run time" system
|> like Python?
|
| Sure, the class behavious is excellent. But the point is, why should functions
| found in a class namespace be converted into methods, but functions found in an
| instance namespace not converted?
|
| For example, suppose you have a running application containing two instances of
| the same class. You need to patch your application on the fly, performing
| *different* modifications on each object. You send a signal to your
| application, and when it is next idle it execfiles your patch script.
|
| This script can modify each instance's variables, rebinding them to entirely
| new objects. In particular, it is possible to hide class variables by adding
| instance variables of the same name. However, with the current behaviour, it is
| not possible to bind instance variables to function objects and override class
| variables with the same name (bound to function objects) without changing any
| other code, because the rest of the program will expect these instance
| atributes to be *method objects*, not ordinary function objects. It is only
| possible to change the class variable, and thus change the behaviour of *all*
| instances of that class.

Well, it's possible, though perhaps not ideal if this were a cornerstone
of your design.  You just have to add the function first to the class
namespace, by whatever name is convenient;  then, you can add another
reference to it in the instance by the name you want, hiding the original
class attribute.  As long as the assignment that creates the second
reference locates the function through the instance, you get a bound
method.

e.g., given class X and instance x,
  x.bindme = x.bindme_new_7       # bound to instance x
  x.bindme = X.bindme_new_7       # unbound

So you're forced to use that class name space, but it's accessible
and if you're worried about collisions, some system can presumably
be invented to avoid them if you're desperate enough.
   
| In a nutshell, I don't see any fundamental reason why the
| search-instance-namespace then search-class-namespace attribute resolution
| order couldn't be used to allow method overriding on an instance-by-instance
| basis. With the current, function-to-method conversion rules, this is
| impossible.
|
| Actually, I'm more curious about why this design decision was made. (Or did it
| just happen that way!)

I sure don't know how anything gets decided.  But I'm pretty sure I've
used this the other way - that is, where the newly added function really
is just a function, not a method.  I don't think that's terribly exotic,
and it's possible due to the way this works.

	Donn Cave, University Computing Services, University of Washington
	donn at u.washington.edu