Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Source Files

• portions of tclObj.c

Public Routines

• Tcl_NewObj
• Tcl_DbNewObj
• TclFreeObj
• Tcl_DuplicateObj
• Tcl_GetString
• Tcl_GetStringFromObj
• Tcl_InvalidateStringRep
• Tcl_DbIncrRefCount
• Tcl_DbDecrRefCount
• Tcl_DbIsShared
• Tcl_InitObjHashTable

Private Routines

• TclObjBeingDeleted
• TclSetDuplicateObj
• TclCompareObjKeys
• TclFreeObjEntry
• TclHashObjKey
• Tcl_RepresentationCmd
• TclFreeIntRep

Directly Depends On Public Routines From

• Allocation
• Hash Tables
• Threads

Directly Depends On Private Routines From

• Event Loops

Discussion

If extensions need TclObjBeingDeleted then it should be public. Otherwise it should be file static.

TclFreeIntRep should be public. There should be no direct calling of another object type's procs.

There's code duplication in TclHashObjKey cribbed from Hash Tables.

Critical defect here: much of the API uses a signed int for object lengths (with negative numbers, typically -1, indicating “use strlen() to get the real length”). This is fine on 32-bit platforms, but massively wrong on 64-bit (except for ILP64 architectures, but that's a rare configuration).

There's a single avenue for transforming from one arbitrary object type to another -- through the string rep. This is effective, but limiting. Fully internal transformations cheat to avoid the problems, notably list to dict and back. This suggests alternative exchange forms could be useful. The two that come to mind are containers -- effectively lists -- and bytearrays.

There's only a single alternative intrep recalled at any time. This is sometimes unwelcome, and a fair bit of trickery is employed in places to avoid loss of a particularly precious intrep. Some consideration of a larger number of alternative representations able to co-exist might be taken. (Pros and cons)