In Snit, you define types; types then have instances. To use a canonical instance, you define a dog type, and then create dog objects. You can define methods and instance variables; and you can define type methods and type variables. Here’s an example:

% snit::type dog {
    typevariable count 0

    typemethod count {} { return $count }

    constructor {args} {
        ...
        # Increment the number of dogs
        incr count
        ....
    }

    destructor {
        # Decrement the number of dogs
        incr count -1
    }

    ...
}
::dog
% dog count
0
% dog spot
::spot
% dog fido
::fido
% dog count
2
%

Here we write a type that keeps track of how many instances it currently has. The point is that type variables are visible without declaration in instance code (e.g., constructor, destructor, and method bodies). In addition, type methods can be called by instance code via the $type command.

Supporting this under TIP 257 is tricky. In Snit, every instance belongs to exactly one type. There’s no ambiguity as to where an instance’s type variables and type methods reside: they reside in the instance’s type.

Under TIP 257, any object has immediate access to its own methods via the my command, and to its instance variables via the my variable command. It can discover its own namespace using namespace current or self namespace, and access its variables by fully qualified paths. The one thing the object doesn’t have easy access to is the class to which it belongs; and so it’s unclear how the object can unambiguously call methods of its class or access its class’s variables.

Just what does a TIP 257 object know about its class? It can retrieve a class name using the self class command; but according to the tip, this returns “the name of the class that defines the currently executing method.” Thus, if the currently executing method was defined by a superclass of the object’s class we get the superclass name rather than the actual class name. So self class is no help.

However, it appears that info object class does the right thing. So our object could call methods on its class in this way:

    [info object class [self]] methodName

Ugh. Sure, it works, but it’s ugly. Further, it means that the object can only access its class’s exported methods, although I can think of cases where an object might want to call some of its class’s unexported methods as well–methods that implement some private resource shared by all instances of the class.

I’ll note in passing that it’s possible to change an object’s class dynamically. (This makes my brain hurt!)

So what about class variables? The only handle we’ve got is the name of the class’s own private namespace. Given the name of that namespace, we can use the class’s my variable command to bring its variables into the current scope. In fact, we can then use the class’s my command to call any of its methods, exported or unexported. And if we were to alias the class’s my command into the object’s namespace as myclass, we’d be really set.

The problem is finding out the name of the class’s namespace, because you can only do that in the class’s own code. I think what iGloo would have to do is pass the fully-qualified name of the class’s my command into each object as it is created; the object can then alias it into its own namespace as myclass. But then, if the object is given a new class we’re in trouble.

Bottom line: In my opinion a myclass command, defined as above, makes a lot of sense. But I think it needs to be defined explicitly as a part of TIP 257; otherwise, it’s too hard to handle all of the edge cases (as when an object’s class is changed).