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/oMaybe 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.
Category Discussion
