[Python-Dev] Classes and Metaclasses in Smalltalk (original) (raw)
Greg Ewing greg@cosc.canterbury.ac.nz
Wed, 02 May 2001 13:22:47 +1200 (NZST)
- Previous message: [Python-Dev] Classes and Metaclasses in Smalltalk
- Next message: [Python-Dev] Classes and Metaclasses in Smalltalk
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Guido:
If both are defined, I propose the following, clumsy but backwards compatible rule: if DictType.dict['foo'] describes a method, it wins. Otherwise, TypeType.dict['foo'] wins.
Yeek! I think that's far too confusing a rule. I suppose it might do in the meantime, but we'd better have a long term solution in mind before going too far down this route.
Ultimately it seems like we'll have to introduce a separate namespace for methods and default instance attributes, say classdict. Then lookup of x.foo would look first in x.dict, then x.class.classdict, etc up the inheritance chain.
Then we'll have to resolve the ambiguity of the class.foo syntax. The bravest way would be simply to change the syntax for getting unbound methods.
The most common use for these seems to be for calling inherited methods, so perhaps something like
inherited MyBaseClass.foo(arg, ...)
which would be equivalent to
getmethod(MyBaseClass, 'foo')(self, arg, ...)
where getmethod() is a new builtin like getattr() except that it looks in the classdict, and 'self' is really whatever the first argument of the containing method was.
Now that we have future, would such a change be contemplatable? Or is it too radical to even think about?
Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg@cosc.canterbury.ac.nz +--------------------------------------+
- Previous message: [Python-Dev] Classes and Metaclasses in Smalltalk
- Next message: [Python-Dev] Classes and Metaclasses in Smalltalk
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]