Forum OpenACS Development: Implementing "Interfaces" using XOTcl

Collapse
Posted by Dave Bauer on
Languages like Java have a built in "interface" concept to define how objects may work together. I don't see this as someting built into XOTcl but I am sure if can be done.

I found this article about adding interfaces to Smalltalk http://www.jot.fm/issues/issue_2002_05/article1 and since XOTcl is highly dynamic simiarly to Smalltalk figured it might be relevant in some way, but its way over he head so far.

Is there any example code that anyone is aware of to point me in the right direction. The main resaon for this question is so far academic. I have been trying to learn about OO programming, and I figured using XOTcl would be more productive than anything else. The basic idea is to take a OO book, which is usually written in Java and translate the examples to XOTcl. This is not hard in theory, and I can usually make someting work no problem. I just don't know if it is the best way to do it.

Collapse
Posted by Tom Jackson on
I thought that XOTcl was more derived from Common Lisp's Object System. There are concepts of generic programming which are very different in concept from Java. I don't know how it works under the hood, but a lot of the terminology is the same. Generic programming is also handled in C++. In Tcl, the functionality of a namespace allows for some features of generic programming. Also, although not OO, when you call a function in pgplsql, the type signature decides which code body to run. The differnce in generic programming is that you can get multiple code chunks run for a single method invocation. It seems too complicated for me to follow, but if you are smart and have a huge project, it might be worth the complexity.
Collapse
Posted by Gustaf Neumann on
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.