Forum OpenACS Development: Re: Implementing "Interfaces" using XOTcl

The concept of an "interface" is quite differently defined depending on the context. The interface definition in Java was introduced as some replacement for multiple inheritance, which is not supported by Java.

In short, an "interface" serves two different purposes:

1. Documentary and publishing purpose: Specify the signatures, on which a developer (not the producer of a software component, but the consumer) can rely on.
2. Enforcement purpose: Specify an interface and enforce that an implementation of the interface implements it

The first category is pretty much in the style of OpenACS and the API browser, where public procs are documented. An API user can use the the API browser to learn the interface. XOTcl supports the flags "public" and "private" for methods and has "documented" and "undocumented" methods (e.g. ad_instproc and instproc). One can consider the public documented methods of an class/object as its interface. The forthcoming XOTcl 1.6.0 goes in many respects further by introducing protected and by providing means for thinner interfaces.

The second category is what's implemented e.g. by abstract classes in C++: one specifies a class definition with the signatures but without concrete realizations of the methods. The method definitions are left out on purpose to be provided by subclasses. By this kind of interface, one would like to specify, that every geometric object has to implement a method draw() or whatever. For such purposes, XOTcl has "abstract instprocs", which are used rather seldom (see below)

This question is also related to the recent discussion about the XOTcl remoting framework and service contracts: A service contract resembles a published interface, which might be published externally through the remoting services via WSDL. In XOTcl service contracts can be provided as XOTcl objects.

Note that in contrary to many other languages Tcl/XOTcl has very rich introspection facilities that makes it possible to query properties of the existing definitions quite easily. Therefore, it is as well possible to annotate methods with flags to be published e.g. for remoting (maybe not all public methods should be available remotely) and providing interface definitions on the fly (not unsimilar to the API browser). The dynamic interface computation has the advantage over explicit entities for this purpose by not having two different things to care about. On the OO case, interfaces can be extended by inheritance or by mixins. One would not like to define the same set of operations on interface objects as well. In short, introspection is a very powerful instrument for component composition and also for interface publication. This does however not hinder to generate (and maybe freeze) explicit interface definitions in an interface repository. We will provide some support in this direction for remoting.

For enforcing interfaces, XOTcl offers many approaches. Aside the mentioned "abstract" declaration, one can use e.g. assertions or filters or explicit checks. But also "abstract" fulfills more the documentation purpose rather than the enforcement character. The basic philosophy of XOTcl more on empowering the programmer than constraining him. See for a discussion a few years ago and a sample implementation for checking by Uwe at http://alice.wu-wien.ac.at:8000/xotcl-mailing-list/0019.html and/or search in the instance for abstract.

Hope this helps a little.