Version 3 of Thoughts on Namespaces and OO

Updated 2006-03-24 14:20:46

Here are some of my thoughts on TCL Namespaces. Here I would like people to put their thoughts on Namespaces.

One of the major strengths of TCL, is having minimal concepts - commands and args and composing complex things out of this.

One easy way to judge a language's simplicity is to see the number of "special characters" in the language.

It seems the namespaces seems to fit into TCL in an inconsistent way. Most of the thing, which are done using infix operator in other languages are done using prefix operator in TCL, to maintain consistency. (Eg. set command is equalavent to = operator).Do we really need a two different concept as Object and Namespace and can we blend those two. Both seems to deal with a way of creating isolated context for procs.

Namespaces - introduce a way of showing relationship using infix operator '::'. Is there a way we can have namespace with prefix operator- ?

Namespaces create a isolated context for procs and their common data. It seems to have more resemblance with class object. Can we integrate these two. So that we need one mechanism to create context, or object. Class objects, unlike instance objects, will have only one instance and can serve the purpose of namespace.

namespace import might become a problem -?. More thoughts are welcome. vkvalli

George Peter Staplin Mar 24, 2006 - The prefix notation for namespaces is interesting. My primary complaint about namespaces in Tcl are that they can still conflict. We could have better namespaces than C++ or Java, because they can be dynamically created. I believe that namespaces should be generated at the time of package require, using the prefix that the user of the code suggests, rather than the package designer's choice. There are various ways of getting around this, such as using namespace eval ${ns} {code here}, or the code at Local Packages and Transparent Namespaces.

Complaint 2. the implementation has undesirable side effects that I've been told can't be fixed until Tcl 9.0, such as: set var global_value; namespace eval ::ns { set var local_value} (which changes the global var, because variable wasn't used to declare? the var). There are also bugs in the tracker involving the current namespace implementation's behavior with traces that have been there since 8.0. It has been stated by several members of the core team that the namespace implementation should have several areas fixed (rewritten), but no work has been started on this.

Complaint 3. the Tcl namespace structures and functions for creating, and manipulating namespaces, have public names (Tcl_), but they are not exported, so extensions must use Tcl_Eval to create namespaces, or risk breakage by including tclInt.h and therefore not work with Tclkit. -George


Category Essay