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

[Evan Simpson]

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.

In my response to GvR's ASCII repost, I realized that I did not have a
decent grasp of what other folks were proposing.  Now I don't even know what
*I* mean by a meta-class any more.

Just van Rossum, Don Beaudry, and MA Lemburg all seem to have roughly the
same idea of what meta-classes would be, and what they would be *for*, but
this idea isn't made explicit, at least enough for my poor brain to get a
handle on it.

John Skaller seems to have a very different take, viewing meta-classes as a
tool for meta-programming.  This seems to involve the ability to make class
factories, which would construct complex functions from simple functions by
much more regular and analytically sound methods than simply compiling a
string.

I'm not sure where Tim Peters stands, except that John's approach really
bothers him <wink>.

As I said, I'm dumping core here, so here's a list of my thoughts and
questions in no particular order:

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).

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?

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?

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.

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.

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.

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.

10. There is no point #10.