Thoughts on Namespaces and OO

Difference between version 12 and 13 - Previous - Next
'''[vkvalli]''' 2006-03-24:   
Here are some of my thoughts on Tcl [namespace%|%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. To maintain consistencey, most of the things which are done using infix operators in other languages are done using prefix operators in Tcl. For exaple, `[set]` equivalent to the `=` 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.

'''[Larry Smith] interjects:'''

Actually, we have a similar conceptual problem with Tk, where widgets are constructed using "." - .menu.submenu.function.edit.  In all these cases we are actually dealing with a list - which Tcl has as a native data type, but we didn't use it, apparently because the original implementors didn't realize these were all congruent concepts.

Ideally, we'd use lists for all this stuff.

======
namespace { top-space local-space this-space } { code }
set { top menu submenu function edit } [ .button ... ]
======

...and so on.  Notice that we have eliminated the need for the infix '::', thereby preserving Tcl's minimalism.

'''[vkvalli] continues:'''

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. 


[George Peter Staplin] 2006-03-24 [PYK] 2020-02-05:  The prefix notation for namespaces is interesting.  My primary complaint about [namespace%|%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 [dangers of creative writing%|%chooses to modify] an existing variable in the [global%|%global namespace] rather than creating a new variable in the current namespace.  There are also [https://core.tcl-lang.org/tcl/rptview?rn=1%|%bugs in the tracker] regarding namespaces and traces.

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 either use `Tcl_Eval` to create namespaces or or risk breakage by including tclInt.h and therefore not work with Tclkit.

[tb] 2007-08-29: I just imported '''[Basique - OO-like namespaces]''' into [TclTalk] and found it quite interesting. I tweaked it a little just to create classes in `::Classes` like `::Classes::File` and also to create the corresponding OO-like routine like `::Classes::File`. I can see all basique classes showing up as children of `::Classes` in the namespace tree and find their class procedures in the `::Classes` namespace. I also tried to create a package from `::Classes::File`, but the resulting package knew nothing about its class procedure in `::Classes`. I'll go on playing with basique, as it would give namespaces a more `OO-like` cloaking.  [http://tcltalk.ath.cx/pub/basique1.01.zip%|%here] is my patched version of basique 1.0.


** Design Principles **


'''[PYK] 2020-03-24:'''

Namespaces are another example of Tcl's philosophy of implementing only the
fundamentals and leaving the rest to the imagination.   The idea of namespaces
is that a namespace is the primitive that underlies higher-level concepts like
"class" or "object".  As often happens with Tcl, it turns out that the
primitive is useful in its own right without the need to resort to those
higher-level concepts.  I propose that for the purpose of designing object
systems, the following principles are implied by namespaces:

   '''Namespaces do not represent objects''':   Namespaces are implementation details, not part of the public interface of an object.  A namespace should not be exposed.

   '''Namespaces are for structuring the program, not the thing being modeled by the program''':   A namespace can not be moved, and this is for good reason.  A program is a virtual machine.  A machine has structure and is typically composed of smaller machines.  Once a machine is built, it might be possible to swap the components out, and even to extend the machine, but one a component is in place, it remains in that place during operation.


   '''Moving an object does not entail changing its namespace''':   The organization of objects and the organization of the program are two separate concerns that should not mingle.


   '''Routines are associated with an object only through some dispatch strategy, not through program structure.''':   This implies that a routine that access the object must receive as an argument a handle for the object.

   '''A set of namespaces contains only the interface to an object''':   Such namespaces might be populated by importing routines from other namespaces.

   '''A set of namespaces contains only the variables that are part of an object''':   This separation keeps the design understandable and flexible.


[ycl%|%ycl ns object] is one system that conforms to these principles.




<<categories>> Essay