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

[Hunter Kelly]

I'm gonna throw my hat into the ring on what I've always thought
meta-classes/were/should be.  I'm going to talk about what I
understand Smalltalk's object scheme to be, with the caveat that I
might be wrong or confused.  There is definitely an area where my
understand breaks down, and it is deep into the metaclass thing.

I'm responding to Evan's mail because what I'm gonna talk about
actually covers three or four of the points he mentioned.  Hopefully,
I'll explain them.

So, basic assumptions about Smalltalk  (this taken almost directly
from the Smalltalk-80 book):

_Everything_ is an object.
An object is an instance of a class.

Thusly, "...classes themselves must be represented by instances of a
class.  A class whose instances are themselves classes is called a
_metaclass_."  

Further on, it goes on to say, 
"Whenever a new class is created, a new metaclass is created for it
automatically.  Metaclasses are similar to other classes because they
contain methods used by their instances.  Metaclasses are different
from other classes because they themselves are not instances of
metaclasses.  Instead, they are all instances of a class called
Metaclass."

So, like Evan's #6, metaclasses contain class methods.  In actuality,
in Smalltalk, constuctors are just class methods, ie, methods of
class's metaclass.

From what I understand, this is pretty much what JvR is talking
about (Evan's #5).

I actually like this thing this way.

It takes care of the type vs class debate, in that there would be no
dichotomy. It makes things pretty uniform, ie, any instance gets its
information from it's class.  For normal objects, this is the obvious
thing, for classes, it means it gets its info from it's metaclass.

I think with a little bit of thought you could extend it to define/change how 
an instances attributes are looked up, etc, etc.  I think it could be
extended to all kinds of fancy things.

A friend of mine once mentioned that, in Smalltalk, he could subclass
Metaclass in such a way as to create a very cool transparent debugging 
scheme.

It is definately a good starting point, and worth considering, in my
opinion.  Python  seems to take the best bits and pieces from various
languages, and, in my opinion, this is one (of many) things that
Smalltalk got right.

Hunter


"Evan Simpson" <evan@tokenexchange.com> writes:

> 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.
> 
> _______________________________________________
> Types-SIG mailing list
> Types-SIG@python.org
> http://www.python.org/mailman/listinfo/types-sig