Source Files

portions of tclObj.c

Public Routines

Tcl_RegisterObjType
Tcl_AppendAllObjTypes
Tcl_GetObjType
Tcl_ConvertToType

Private Routines

TclInitObjectSubsystem
TclFinalizeObjects

Directly Depends On Public Routines From

Directly Depends On Private Routines From

None

Discussion

Given the benefit of years of experience with the Tcl 8 stork model of values, this entire module is believed by many to have been a mistake. It exposes enough of a mechanism to give any arbitrary code the power to set a particular internal representation as managed by other arbitrary code. This is typically a mistake, as only the code written to create, maintain, and return a particular internal rep really knows when it is proper to store it in the value. Typically, any caller of Tcl_ConvertToType on a type not of its own responsibility, is going to act on knowledge about the internal rep, breaking the encapsulation, and setting up fragility when the implementation of the type is revised.

In place of Tcl_ConvertToType, any object type that can usefully export something from its internal representation ought to define an appropriate GetFooFromObj routine. The details of each routine will depend on the nature of the value stored, so it seems it ought not be a general interface. If it is determined that a general solution has to be offered, then presumably it would be oriented around ClientData.

Without Tcl_ConvertToType to service, there is no longer any need for any type to define a setFromAnyProc. Instead, the same function would be in whatever GetFooFromObj routine it may supply. Also with no Tcl_ConvertToType to call, there is no need for any caller to access an arbitrary Tcl_ObjType, so there's no need for Tcl_GetObjType. And if no Tcl_GetObjType will be pulling types out of registration, then no Tcl_RegisterObjType needs to put them in there, nor do we need any mechanism to list the types available. In fact, there's ultimately no need for an object type to have a string name at all (though it is helpful in error reporting and debugging with the representation command). The end result is a system with far greater decoupling, where every Tcl_ObjType struct can have file static scope, which is helpful for independent, non-coordinated development of interoperating modules.

Besides the advantages of a more decoupled system, there are other problems with object type registration in that it has never been well defined how to properly resolve any collisions in the object type names by which registration happens. Neither option of either raising errors on collision, nor using collisions as a means to replace and retrofit has been embraced. All that has been done is to avoid collisions as much as possible.