Method objects question

[skaller]

Tim Peters wrote:
> 
> [Ben Caradoc-Davies]
> > ...
> > 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?
> 
> Both behaviors are useful, depending on the application.  Guido picked the
> behaviors for each mechanism that he judged would be most useful most often.

	Twaddle. It is a hack, plain and simple.

> > 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.
> 
> There is no "fundamental" reason.  

	Yes, there is: if every callable object (or, just functions)
were bound, then no callable objects (or, just functions) could be
instance attributes, since they'd be bound when you didn't
want them to be. This is already true for classes, and it is a pain.

	The correct solution, IMHO, is to have two dictionaries,
or perhaps a flag, to distinguish attributes and methods.
Another is to redesign the language, so 

	x.y()

causes binding, but

	x.y

does not.  Another solution is a separate operator, say:

	x -> y # binding done
	x . y #  no binding

Viper uses the same mechanism as Python here,
unfortunately: if an attribute is callable, it is automatically
bound to an object when fetched. My implementation of classes
actually has two dictionaries, one for methods, and one for
non-methods -- but I don't use the method dictionary, because
I couldn't figure out how to retain python compatibility
if I did.

-- 
John Skaller, mailto:skaller at maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850