Victor,
Kristoffer already provided you with a primer ...
I've been looking everywhere and can't find the info.
I am wondering why you are looking for that concept in the XOTcl-verse? Out of curiosity? Or, because you assemble your arsenal against your Java, C#, C++ background?
There is a prior thread on this issue which provides a pretty precise picture on that matter:
http://alice.wu-wien.ac.at/pipermail/xotcl/2000-December/004148.html
To sum it up, you won't find a direct equivalent of "abstract class" as you might know it from languages cited above. But the key message of the thread by Uwe Zdun is that you can approximate and, finally, build it on your own ...
Abstract class can take the following semantics which are not mutually inclusive (!):
~ A class object that, at least partially, consists of /abstract methods/. Abstract methods do not provide an implementation (method body).
~ A class object that is constraint to participate only in superclass-subclass relationships, i.e. participate only as superclass/subclass in an object system. In other words, a class that can not be instantiated.
~ A class object that requires its subclasses to provide implementations (method bodies) for the set of its abstract methods.
Any of the three aspects may be approximated in XOTcl (as shown in the thread), but still, the concept will differ. Many issues blur the picture, for instance, time of enforcement of the abstract class constraints (there is no compile time in XOTcl!).
The notion of "abstract class" comes with many connotations, but its purpose has been prominently linked to their use in terms of OO frameworks as promoted by Ralph Johnson & Co. This is inherently linked to the need of /integrating/ a framework into a final application with integration meaning completion. Completion, in turn, realises as refining "abstract classes" into concrete subclasses provided by the framework.
Another perspective is considering the need for a /type hierarchy/, on the one, and an /implementation hierarchy/, on the other hand. Note, that type here not necessarily means "behavioural type" in the Liskov sense of the term. Type hierarchies are commonly realised by the well-known "interface" constructs in languages such as Java and C#, and the importance of interface-oriented programming gained some momentum in recent years (while it was the default in years of CLU and Emerald, but anyway). Implementation hierarchies, on the contrary, are commonly realised by class-based inheritance hierarchies. The trade-offs of using inheritance for realising both type and implementation hierarchies is widely discussed in literature. Abstract classes somehow settle in the middle. With abstract classes meaning collections of abstract methods, methods that comes without a method body (=implementation), you can approximate the idea of interfaces (as member of a type hierarchy).
Finally, at a higher level, abstract classes may help realise valuable forms of OO design, the most prominent example being the GoF TEMPLATE METHOD pattern.
Hope it helps to clarify the picture a bit ... //stefan