CMcC Two fundamental types in tcl core are Tcl_Obj and Command.
Both maintain some state, are refcounted, can be named and define some intrinsic operations.
Purposes:
The first element of a string to be evaluated must be a Command. The primary carrier of value is a Tcl_Obj.
Tcl_Obj's are arguments to and results from evaluation of Commands.
In short: Commands evaluate Tcl_Objs.
Anatomy:
Tcl_Obj is typed, and provides the following operations:
Tcl_Obj provides for a string representation and an internal representation comprising storage for up to two pointers.
Command provides the following operations:
Command provides state comprising: a binding, a list of namespace import references to this command, and most importantly: client state associated with the Deletion and Evaluation operations.
Similarities and Differences:
Both can be deleted.
Tcl_Obj can be duplicated, and can mutate some other value to itself, and itself to a string.
Command can be evaluated and compiled. Since a Command is inherently named, duplication makes no sense, because duplicating a (name,value) pair is always an identity. However, rename can be considered a similar kind of function, in that it creates identical state with a new binding.
Command doesn't have a string representation, doesn't provide a Serialisation operation. This makes sense, to some extent, because its state (comprising C functions) is not meaningful as strings.
proc is the only way to transform a Tcl_Obj into a Command in vanilla tcl. itcl and xotcl provide other ways to generate Command from Tcl_Obj.
Unification:
Notwithstanding the differences between them: If a Command were represented as a Tcl_Obj, how would it look?
If we wanted to create a Tcl_ObjType which wrapped a Command, we would be trying to provide meaningful equivalence between the Tcl_Obj operations (Deletion, Duplication, Serialization, Mutation) and the Command operations (Deletion, Evaluation, Compilation)
Evaluation and Serialization seem most closely analogous, in that All Commands can be Evaluated and All Tcl_Obj can be Serialized. It may be that a CommandObj would use Tcl_Obj Serialize to Evaluate.
Command consumes Tcl_Obj arguments and generates a Tcl_Obj result, remaining (itself) unchanged, Tcl_Obj can clone itself, and can absorb (almost digest or metabolise, also shimmering) other Tcl_Objs into itself.
Most Tcl_Obj processing would be consumed in metabolising, just as most Command processing is consumed in evaluating. Both mutation and evaluation result in a transformed object (from the list of args to a result in Command, and from the object to its new form in Tcl_Obj.)
Much of the design of Tcl_Obj revolves around the need to refcount, much of the design of Command revolves around the need to bind.