[Xotcl] Abstract class

[Stefan Sobernig]

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

-- 
Stefan Sobernig
Institute for Information Systems and New Media
Vienna University of Economics	
Augasse 2-6
A - 1090 Vienna

`- +43 - 1 - 31336 - 4878 [phone]
`- +43 - 1 - 31336 - 746 [fax]
`- stefan.sobernig at wu-wien.ac.at <mailto:stefan.sobernig at wu-wien.ac.at>
`- ss at thinkersfoot.net <mailto:ss at thinkersfoot.net>