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).