Not to be confused with TclOO.
The following code is somewhat experimental. I have seen quite a few variations on this theme. However, I believe this code does things in a new and interesting way. This code is not feature complete, it is primarily a proof of concept at this point. Please feel free to make comments and/or criticize this code. If you have feature/code suggestions please feel free to add them to this page. If you would like to submit code changes, please email them to me and I will review them for addition.
This code allows for the following concepts/constructs:
The only "missing" things that I can think of so far are:
This code is now too big for a WiKi page (about 100K, including test files).
It may be downloaded from: http://www.tclbridge.com/tcl_oo.zip (link is dead, I need to find that now somewhat obsolete code and put it back up -- JJM).
Here's a simple example of how to declare and use a class with this OO system...
class demoClass {
option alias.primary
option proc.trace.outer
option proc.trace.inner
variable x
variable y
variable z
variable array_variable
comment {
#
# override global proc locally...
# (notice we call the global proc from inside it)
#
}
proc class_output { output } {
::class_output "$this: $output"; # calls global proc
}
proc constructor { object args } {
class_output "NEW: $this"; return "1"
}
proc destructor { object args } {
class_output "DELETE: $this"; return "1"
}
proc doNothing {a} {}
proc simpleReturn {} { return $x.$y }
proc returnMethod {a} { return [doNothing $a] }
proc callMethod {a} { $this doNothing $a; return $x }
proc testArray {} {
set array_variable(1) "element1"
set array_variable(2) "element2"
set array_variable(3) "element3"
return [array names array_variable]
}
}Written By Joe Mistachkin
Version History
Wishlist:
I first thought I'd be joking, but I just saw there is a large source file to implement all the well known oo features. Good reference list. Good also to decide without much trouble that oo is a rather limited extra as compared to well defined source code buildup and data structures, and in fact nearly always generates a price to pay in less efficiency of the code (it never adds something that makes our processors tick through the essential algorithms faster) and it always adds overhead in source and usually object code size (re-usability of functions or procedures works just fine with traditional functions, just reuse them..), and the structure of ordering things in one or multiple trees hierarchy is somewhat practical, but not as standard ordering paradigm more than in functions in groups.
Not so much intended for the author; I did years of research fruitfully using an oo language, and I generally like the idea that everything works through list commands of solid structure and maintainability, like in tcl, except when one needs the added speed of extra compiled code. It serves at least as great instructional value, and can be a hell of a lot safer to use and overseeable to maintain and debug.
JJM 09/Apr/2003 -- I appreciate your feedback. Let me see if I can address your wishlist one by one:
I could imagine when sending messages between objects that the addressing of objects, or maybe of uniquely referencing to a certain object in a certain class could include using the (class hierarchy based) path to that object:
[send target_class.target_subclass.targe_tobject message]
Streaming would indeed suggest the possibility of persistence, though I didn't mean that, I just meant that at least at times it would be good to see the structure of the instantiated object tree printed somehow, and possibly get some file savable or probably even better concept 'listable' representation of the data in some subset of all objects. Like a favorite of mine would be to send the root object (if there is one) the message 'save' and that one would get a list returned where each object has a sublist which for instance lists its variable contents.
The fun of tcl is that, as I wrote, I was being sort of funny-like about for instance type casting: since mostly everything is a list, there is not much point in casting a list to a list 'formally'; practically of course one can do what seems fit for a certain purpose....
escargo - I know I took the "message sending to be of the nature of Smalltalk message sends. Certainly the notion of having self be a specially value relates to that as well.