[Types-sig] Q: What are Meta-classes anyhoo?

[Gordon McMillan]

[Evan regrets opening his big mouth, threatens to change his name to 
Thelma and move to Polynesia...]

> I meant to keep up with the the discussion following my overly-bold
> meta-class post (provoking discussion was my intent, and it has been
> amply fulfilled), but have been ill and cut off from the Internet
> for two days. Now I've read it all, and I'm going to dump mental
> core all over the place.

Well at least you didn't have to scrape it off the walls and send it 
to us!

> 1. We really want to do away with types vs. classes, and making
> types *be* classes is the general favorite approach.  Since every
> object has a type, this means that every object will have a class. 
> Including classes (thus meta-class).

By itself, it just means things like ints and floats are classes. The 
fact that classes are likely to have classes is toxic gravy.

> 2. Types are inert lumps, good only for identity comparisons with
> other types.  Classes provide default attributes and methods to
> their instances. Classes *get* default attributes and methods from
> their base classes, in a very powerful and useful way.  What should
> they get from their meta-class?

Oh no! Types have methods and state, it's just that they are only 
minimally manipulable from pure Python.

> 3. JvR+DB+MAL, if I'm reading them right, have meta-classes defining
> or possibly subverting what it means for an object to be a class or
> an instance.  Am I reading this right?

Yes. But there's lots of room for argument about what is meant by 
"subvert", "class", "instance" and even "is".

> 4. For example, MAL has the meta-object "Instance" of an instance
> (which is
> *not* its class!) control how the instance finds attributes outside its
> dictionary.
> 
> 5. JvR would have the class of the class of the instance take this
> meta- role.  Similarly, the class of the class of a class would
> define attribute search and instance creation for the class <head:
> boom>
> 
> 6. DB, on the other hand, seems to suggest in one message that a
> meta-class' methods might merely define static methods of its
> classes, just as class methods define static (read "bound") methods
> of its instances.  I sort of took this view initially.

Here, I think, you're running into the difference between the 
"theoretical" view and the "practical" view. In the former, it's all 
important that everything be an object, and that all objects be 
instances of classes, recursing to a Deus Ex Machina. However, even 
the venerable (and quite mad) Don Beaudry, who created the hook in 
the first place and went furthest in making a theoretically pure 
implementation, admits that he has no idea what this conceptual 
purity buys you, other than the ability to be a sanctimonious madman.

The "practical" side is concerned with doing __getattr__ and 
__setattr__ hooks in a manner that doesn't cause people to confuse 
you with Don Beaudry.

GvR's ASCII art and MAL's proposal are firmly in the latter camp - 
separate the machinery from the attributes. Just's is too, even 
though it looks more and more Don-ish all the time.

(A naive observer might expect Tim to favor the former, as it has no 
known usefulness.  But I suspect he's sees more ability to subvert 
usefulness in the latter.)

> 7. Since attribute search behavior is the only example I've seen of
> the meta- role's functionality, it's not clear to me how this is
> superior to sub-classing with a mixin.  Mr. Lemburg's __meta__ stuff
> in particular bemuses and befuddles me, since it seems to have
> little or nothing to do with point #1.

Subclassing with a mixin doesn't let you, for example, interfere with 
how an existing attribute is accessed. The general idea here is to 
kidnap the object, skin it, then waltz around in public impersonating 
it. All without letting the programmer / user know he's been 
bamboozled.

> 8. Another point of view (Mr. Skaller's, I think) is that class
> objects build instance objects, albeit in a fairly passive way. 
> Thus, meta-classes should build classes, but in a more active
> fashion than simply acting as a template/default-attribute map
> (which base classes do anyhow).  I have vague visions of filling in
> class methods by combining sub-function code snippets in interesting
> ways.

John speaks exotically, but the idea is much the same. Meta-classes 
create classes, but what we're looking for is ways to change the 
class plumbing. Who says a class has to hold it's attributes in a 
dict? Maybe it holds them as slots for faster access, but you have to 
promise that the table of slots is fixed at __init__ time. Then the 
meta-object is in charge of making sure that other objects don't have 
to know that this class is implemented very differently.
 
> 9. Might this be too static, since changing a meta-class would be
> like changing a class' __init__ rather than like changing its
> dictionary?  That is, the meta-class is only executed to build the
> class, not dynamically searched.

The point is that it's in charge of how the search is performed. 
There's nothing static about it, or at least there won't be unless 
Roger breaks out of the isolation ward.

> 10. There is no point #10.

Good, I was running out of people to offend!

metaclasses-for-the-metaclueless-ly y'rs

- Gordon