Okay, here's a sketch of where I'm going with the initialization,
finalization, and fallback method locating. We need to do this
because we're in the semi-unenviable position of supporting multiple
languages that do this but that *don't* aggree on method names. So we
can't depend on those.

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
d...@sidhe.org                         have teddy bears and even
                                       teddy bears get drunk