[Types-sig] MetaClasses (Non-ASCII art)

M.-A. Lemburg mal@lemburg.com
Thu, 03 Dec 1998 10:43:05 +0100


Just van Rossum wrote:
> 
> Me:
> >> I'm not sure why inheritance needs te be brought up here (or in any
> >> metaclass discussion) at all: how exactly it works is to be defined by
> >> class.__meta__.
> 
> M.-A. Lemburg wrote:
> >Inheritance for meta objects can be very useful, e.g. in case
> >all you want is to refine say the __meta_getattr__ method of
> >Class to enable automatic acquisition or caching. You won't
> >have to copy all the other implementation details: inheritance
> >does this for you.
> 
> Sure, just add one more meta level which just implements
> inheritance and you're still done...

Ok, point taken, would cause a lot of overhead though...

> Me:
> >> What I'm really saying is, if you define
> >>         getattr(object, attr)
> >> as
> >>         object.__meta__.__meta_getattr__(object, attr)
> >> or as
> >>         object.__class__.__class__.__meta_getattr__(object, attr)
> >> You're basically done. The rest is implementation details... Now, which one
> >> will it be?
> 
> M.-A. Lemburg wrote:
> >Not really: classes and instances do different things to get
> >at their attributes. Instances revert to their classes for help
> >if they can't find an attribute, while classes try their
> >base classes.
> 
> Sure, but they're _both_ implemented as classes, and they
> just happen to define __meta_getattr__ differently. I don't see
> how this has anything to do with inheritance. The class protocol
> defines inheritance, but might be implemented using a meta
> protocol which doesn't do inheritance. Or one that does, but that
> one might be implemented using a meta protocol which doesn't
> do inheritance. Or one that does, but that one might be
> implemented using a meta protocol which doesn't do inheritance.
> Or one that does, but that one might be implemented using a
> meta protocol which doesn't do inheritance.

Right. I just find it a little confusing searching for the
meta object (implementing the object's behaviour) in
obj.__class__.__class__ because that reminds me too much of
how Instances and Classes relate to each other. 

The meta protocol could very well also be used for other objects
types which don't rely on underlying Classes. Coming to think
of it... these __meta__ object have a lot in common with the
type objects: only that type objects are a symbiosis of behaviour
*and* implementation. Maybe there's a possibility there...

Also, it could allow changing the behaviour by reassigning a new
meta object to obj.__meta__ on a per object basis.

And last, not least, it avoids one level of indirection
in the implementation (though this could probably be simulated
by caching __class__.__class__ into the __meta__ attribute).

> >> The last line can't work because
> >> - MyClass is in instance of MyMetaClass
> >> - MyClass.__init__ will be found in MyMetaClass *before* it can trigger any
> >> __getattr__ that could look it up inside MyClass.
> 
> M.-A. Lemburg wrote:
> >That's why meta objects should have a hook that controlls *all*
> >getattr-actions, e.g. __meta_getattr__.
> 
> Yeah, they _should_, but I'm talking about this from the perspective of
> trying to implement such a thing using Python _today_. I get a long way by
> defining an alternative __dict__ and the usual __{get|set|del}attr__ cruft,
> but this was a (veryveryvery*very* minor) point where today's Python
> implementation let me down...

I wouldn't be afraid of thinking big: a rewrite of some of the
stuff in classobject.c wouldn't hurt much and there's still a
lot of time 'til 1.6 comes out ;-)

-- 
Marc-Andre Lemburg                               Y2000: 393 days left
---------------------------------------------------------------------
          : Python Pages >>> http://starship.skyport.net/~lemburg/  :
           ---------------------------------------------------------