Peter Newman 10 January 2005: -------------------- Unified Programming Language
Traditional Tcl
Traditional Tcl is command-oriented. In that each 'line' of code consists of a command name - which is supposed to be the first thing on the line - followed by the command's arguments.
This seems to be an essential feature of Tcl; so if we're going top make a Tcl/2, it seems that we should keep it.
Object-Oriented Tcl
But there also seems to be a huge demand for an object-oriented Tcl. As best I can tell, probably as much of 50% of Tcl'ers would like an object-oriented form of the language. And that seems true of programmers and programming languages in general. Python and Lua are 100% object-oriented (from the little I know about them). And Perl and C++ are about 50% object-oriented.
So if we're going to re-design Tcl, then implementing an object-oriented form of the language seem to be desirable.
Doing Both
Fortunately, with UPL, we can do both. UPL is a framework that allows each individual programmer to select/create the programming language of their choice. So we can (and IMHO should,) develop both a command-oriented and an object-oriented form of Tcl/2.
The Object-Oriented Flavour
Another issue that arises is "Which form of object-oriented syntax should we use" (there seem to be many competing flavours out there; Incr Tcl, Snit, etc). Fortunately, with UPL it doesn't matter. Anybody that wants to implement this or that particular syntax can simply do so.
Object-Oriented Traditional Tcl
Traditional Tcl, or more precisely Tk, is already somewhat object-oriented. Consider:-
frame .myFrame .myFrame cget -borderwidth.
Although .myFrame is a command, you can also think of it as an object, with method cget and property -borderwidth.
This idea can easily be extended to standard traditional Tcl commands. Check out SS's cfile - where he's basically implemented the standard I/O commands in objected-oriented form. The file handle becomes an object ID. And things like; read, close, seek, tell and puts, etc, become the methods that it supports.
So one quick and easy way of making Tcl more object-oriented, would to convert all of Tcl in a similar manner.
Implementing an object-oriented Tcl this way is (IMHO,) the best way to go. It's quick and easy - and reasonably familiar to traditional Tcl/Tk programmers. It's also compatible with traditional command-oriented Tcl; the two can live side by side in the same parser.
In addition, these new Tcls aren't an end in themselves. They're really just two languages we're using to develop and test UPL with. So we don't want to get bogged down with the syntax of them. Refining and creating the syntax of the new Tcl/2, is really something to be done once UPL has created the framework that makes this possible.
TCL/c & TCL/o
Maybe we could call these two new prototype Tcl/2's; Tcl/c (for the command-oriented one) and Tcl/o (for the object-oriented one).
PWQ 17 Jan 05, Tcl needs an OO system like a Whale needs a bicycle!
The fact that numerous OO extensions exist as script or loadable libraries somewhat negate your (PN) argument for something special to be done in TCL/2.
There are issues around shimmering that occur when using $obj as an object and command which could be addressed. But that also occurs in other contexts as well, so a general rather than OO specific solution needs to be found.
Peter Newman 17 January 2005: Yeah, I personally don't like OO. But heaps of people do. And there are lots of calls for OO to go in the core (though one gets the impression that few on the core team are that enthusiastic about this).
But I was trying to point out that with UPL it doesn't matter. If someone wants to implement Tcl this or Tcl that, they can do so. So we don't have to argue about whether Tcl should or shouldn't have this or that feature. Every data type and command is a completely independent, script-level programmer selectable entity. So if someone wants to do OO stuff, that's OK. Others can either use it or ignore it, as they see fit.
And unlike current Tcl, ignoring it doesn't mean just not using it. It means you don't load the modules/DLL/sos implementing the feature. So it's not cluttering up your system - or bloating your distributions. It's not even in it/them.
Similarly, OO programmers can ditch the command-oriented stuff (if they want to). For a totally OO system.