What I'm thinking of instead is to put properties on the class namespace PMC that indicate which method, if any, in the namespace is the proper method. And because initialization and finalization are... interesting (don't ask, we'll go there later) we actually have two of each.
So, what we're going to do is introduce six properties:
FALLBACK CONSTRUCT BUILD FINALIZE DELETE CLEANUP
FALLBACK is the method we look for if we've redispatched up the whole darn tree and haven't found what we're looking for. It's the equivalent of perl's AUTOLOAD.
CONSTRUCT is the method we call when we're building the object from scratch. We call it on the object and if the object wants to redispatch to parents, it better do so. We'll catch that it's being redispatched and call the proper parent class method even if it has a different name.
BUILD is the method we call when we're building the object. We call this on *every* class in the object's hierarchy that it exists in. No redispatching, it's all automatic.
FINALIZE is the method we call when we're destroying the object. It's the equivalent of perl's DESTROY or python's __del__ method. We call this on the object like a normal method--we find one and call it and that's it. If a class wants to redispatch it better do so. (And we'll catch redispatching __del__ in a python class that inherits from a perl class and call perl's DESTROY instead, as we're redispatching based on the function not the method name)
DELETE is the equivalent of a C++ destructor. It's called on every class in an object's hierarchy that it exists in.
CLEANUP is the method that's called when an object dies. It's a class method rather than an object method. (It's a ruby thing, I'll get more details later)
What happens if a class hierarchy has a mix of CONSTRUCT and BUILD methods, or FINALIZE and DELETE methods? Beats me.
Also, these properties are on *names*, not method PMCs. We get a two-step "look up the property, then look up the method the property names" thing, so we don't have sync issues when people replace the method body PMCs at runtime by redefining the methods. (Or when we've got locally obscured namespaces and should then pick up the current version of the method)
At the moment I think we're going to allow reparenting, but that's going to require catching pointer stores, so that means we're going to need to start shimming in the pointer store function stuff that we've been mildly pondering for the generational GC.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
