D 2014-09-16T00:57:45.858
L Tcl_Obj\sSystem
P 1c93cad07979a330be56a623fa557a7975ba30ab
U dgp
W 3435
<h1>Source Files</h1>
  *  portions of [/finfo?name=generic/tclObj.c|tclObj.c]

<h1>Public Routines</h1>
  *  Tcl_NewObj
  *  Tcl_DbNewObj
  *  TclFreeObj
  *  Tcl_DuplicateObj
  *  Tcl_GetString
  *  Tcl_GetStringFromObj
  *  Tcl_InvalidateStringRep
  *  Tcl_DbIncrRefCount
  *  Tcl_DbDecrRefCount
  *  Tcl_DbIsShared
  *  Tcl_InitObjHashTable

<h1>Private Routines</h1>
  *  TclObjBeingDeleted
  *  TclSetDuplicateObj
  *  TclCompareObjKeys
  *  TclFreeObjEntry
  *  TclHashObjKey
  *  Tcl_RepresentationCmd
  *  TclFreeIntRep

<h1>Directly Depends On Public Routines From</h1>
  *  [Allocation]
  *  [Hash Tables]
  *  [Threads]

<h1>Directly Depends On Private Routines From</h1>
  *  [Event Loops]

<h1>Discussion</h1>

If extensions need <b>TclObjBeingDeleted</b> then it
should be public.  Otherwise it should be file static.

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

There's code duplication in <b>TclHashObjKey</b> cribbed from
[Hash Tables].

Critical defect here: much of the API uses a <i>signed int</i> 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)

Each object type fully controls the creation, duplication, and release of the internal rep.
However it controls only the creation of the string rep.  The overall value system defines
that when it is time to release the string rep, it will be done with <b>ckfree</b>.  This
implies that every string rep must be a separately <b>ckalloc</b>'d chunk of memory
and that implies a fair bit of memory management and string copying.  The expense of
this is mitigated by the Copy On Write scheme that keeps the number of values that
are nothing more than copies of others down.
Offering the object type control over the release of string reps would allow for other
possibilities, where a set of values drawn from a small set of static strings might be
done without memory management.  Or string reps could be substrings of other
strings kept alive via whatever means is required.  This would imply relaxing the
current requirement that objPtr->bytes values are NUL-terminated.

The reference counting scheme used to manage copy on write as well as memory
management brings with it the constraing that these values are tied to a single
thread at a time, and except where special care is taken that means a Tcl value
is born, lives, and dies all in one thread.  Values that must pass from one thread
to another take a route through a strip representation.

Z 7dd65472c391374d2487935888c5d36e