[Xotcl] TIP #257: Object Orientation for Tcl

[Kristoffer Lawson]

On 26 Sep 2005, at 20:40, Jeff Hobbs wrote:

> I know that many on this list will be interested in the
> following TIP just propsed:
>
>     TIP #257: Object Orientation for Tcl
>     http://www.tcl.tk/cgi-bin/tct/tip/257

First, I want to say I'm very excited about this TIP. If this goes  
into 8.5 I'd really like to see a big concentrated effort to get Tcl  
back on the map. Even Ruby is getting more press than Tcl right now  
and this needs to be changed. If Tcl includes an OO infrastructure  
with it then that might help with the push. It is essential we do not  
do this in a manner that says, "Me too", but to display the diversity  
and the elegance and power of Tcl. Tcl is a command-oriented language  
(instead of object-oriented), but that simple principle offers us  
ways to extend it in all kinds of directions. When a new paradigm  
appears, Tcl will be able to handle it too.

This is not Tcl going OO after many years of dilly-dallying, but  
providing a sound foundation which supports a wide range of  
extensions that have already existed. It's about making coders' lives  
easier.

I do have some comments on the TIP (no surprises there):


* The description about filters at the top of the TIP is not  
necessarily totally in line with XOTcl. Filters are not only about  
deciding whether a method is called but can also manipulate the  
message which is being passed. They can catch and do anything really.


* Mixins in XOTcl are classes which are dynamically mixed into the  
normal object inheritance chain. The mixins based on the TIP seem to  
be about mixing in procedures, which would be quite different.


* I disagree with the need for exported/non-exported methods. It adds  
complexity and for what? How is method lookup solved? Can sub-classes  
access non-exported methods? If not, wont that lead to problems for  
extensions? If they are seen, can they be overridden, even by  
accident, with public methods? Basically I see the whole business of  
private/public as mostly a documentation issue. There could be a  
mechanism in place for auto-generating docs on certain methods but  
not on others, but with no actual separation between the two. I  
believe Python follows this model to some extent. Convention versus  
forcing.

Besides, any mechanism such as the one described can be implemented  
by the use of filters. Filters offer much greater flexibility in this  
respect and finer granularity. I've never actually felt the need for  
public/protected/private/package.


* It is not true that XOTcl's creation mechanism makes it difficult  
to do Tk-like option handling.

The -dash arguments (or methods) are called before the constructor.  
The standard XOTcl way to do Tk-like options is to make the options  
into so-called parameters. Parameters are basically instance  
variables which have setter/getter methods attached to them. This  
leads to Tk-like option handling:

Class Car -parameter {
     {doors 5}
}

set myCar [Car new -doors 3]


* I disagree with not making constructors methods. This is something  
I find to be a nuisance in Java. They act a bit like methods but  
aren't really methods. So I can't use normal inheritance rules to  
automatically get a constructor from a super-class. This is  
especially annoying with Exceptions which are often nothing more than  
a new classification and have no added functionality whatsoever. It  
also means a completely new mechanism needs to be in place for  
constructor introspection and manipulation. In XOTcl this is trivial  
as the constructor is a method like anything else.

Objective C uses the init method as a constructor (by convention) and  
does not cause problems. I've never heard of anyone trying to call  
[init] on an XOTcl object again. It all sounds a bit like a case of  
premature protection --- something which often bothers me. Protection  
makes a system more complex and often is not really needed.  
Protection hasn't ever been a theme in Tcl. Let the user and  
developer decide.


* Destructors. Same thing. Why? Why have something which adds  
complexity when a method can manage the same? With methods the  
implementation can decide whether to use the destructors further up  
(there might be cases when this is not desired), or in what order to  
apply its own cleanup and super-class cleanup.

I do agree that a [destroy] command might be a good idea. In fact,  
I'd go the whole way and stick it on the top level. I know [rename]  
can manage the same, but it's not totally obvious and then we'd have  
one mechanism that does the same for anything. Oh, and whatever the  
destructor does, I do believe it should not be allowed to prevent  
destruction of the object (unless the [destroy] command is manipulated).


* I agree with the class vs object method naming convention.


* Having instprocs named methods sounds like a good idea.


* What about child objects? XOTcl provides a mechanism where an  
object can be created as a child of another. If the parent object is  
destroyed, the child is automatically destroyed too. This is often  
useful and provides an alternative for one common area helped by  
garbage collection (as long as these child objects are never used  
anywhere else).



            /  http://www.fishpool.com/~setok/