[Tcl-bugs] [ tcl-Feature Requests-219316 ] Garbage collection of object oriented Tcl commands

[SourceForge.net <no...@so...>]

Feature Requests item #219316, was opened at 2000-10-26 06:10
Message generated for change (Comment added) made by dkf
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=360894&aid=219316&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 47. Bytecode Compiler
Group: obsolete: 8.4a3
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Donal K. Fellows (dkf)
Summary: Garbage collection of object oriented Tcl commands

Initial Comment:
OriginalBugID: 3678 RFE
Version: 8.2.1
SubmitDate: '1999-11-23'
LastModified: '2000-04-03'
Severity: LOW
Status: UnAssn
Submitter: techsupp
ChangedBy: hobbs
OS: All
FixedDate: '2000-10-25'
ClosedDate: '2000-10-25'


Name:
Chris Oliver

DesiredBehavior:
Several packages such as TclBlend and TclMico implement a form of
automatic garbage collection for Tcl commands that represent object
instances (Java and CORBA respectively).  However they do this with a
rather gross hack, namely by overwriting the global "cmdName" Tcl
ObjType with their own implementation. The replacement implementation
deletes such a command from the interpreter when the the last Tcl_Obj
that references it is destroyed.

A couple of minor changes to the Tcl core would allow these and other
object oriented Tcl extensions to provide the convenience of automatic
garbage collection to the script writer, without resorting to such
hacking.  I will describe these changes in terms of a possible
implementation, however other ways of achieving the same result are
possible:

1. Add the following new interface:

    TclCommand Tcl_CreateObjCommandEx(Tcl_Interp * interp, char *
cmdName,
                    Tcl_ObjCmdProc * proc, ClientData clientData,
Tcl_CmdDeleteProc * deleteProc, /* boolean*/ int collectMe);

2. Add a corresponding field to struct Command:
    struct Command {
        ...
        int collectMe;
    };

Tcl_CreateObjCommandEx uses the current implementation of
Tcl_CreateObjCommand but also assigns the value of its collectMe
parameter to the collectMe field of the created struct Command.

Tcl_CreateObjCommand can be reimplemented as

    Tcl_CreateObjCommandEx(interp, cmdName, proc, clientData,
deleteProc, 0);

3. Modify `tclExecute.c`FreeCmdNameInternalRep to check the reference
count of the Command struct it points at; if it is about to reach one
(i.e. the only reference will be that of the Namespace hash table) and
its collectMe field is non-zero, then call Tcl_DeleteCommandFromToken on
the Command pointer.

At any rate, the basic idea is that Tcl would ask the command's
implementation if it wants to take action when there are no further
references to it.

Comments?





----------------------------------------------------------------------

>Comment By: Donal K. Fellows (dkf)
Date: 2009-03-24 16:24

Message:
Note — mainly so *I* don't forget — long-term want the things returned
by TclOO's [$cls new] method to be GCed (unless they get [rename]d). Also
see what tdom and tcom do.

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2001-01-09 14:56

Message:
Further discussion indicates that for this to be truly useful, great care
will need to be taken to ensure that object-representations of these
commands don't get lost too easily (Tcl_Objs were designed with the
intention that the non-string form be just a cache of what would always be
creatable from the string form, and not vice versa.)  This requires doing
something much smarter than at present with substitutions into strings (the
main way of accidentally losing non-string forms.)

----------------------------------------------------------------------

Comment By: Donal K. Fellows (dkf)
Date: 2000-11-08 11:33

Message:
Seems like a reasonable idea to me to add "unnamed" commands that
get GCed when their last reference disappears.  It would also be useful in
Itcl and many other places.  Support for this could be done instead by
making Tcl_CreateObjCommand() produce this sort of command when a NULL or
empty string is passed for the command name (currently an error, or at
least darned well ought to be.)  This would have the advantage of avoiding
the horrible ...Ex function naming convention (which was invented by
someone deeply demented; that MS use it a lot doesn't surprise me in the
slightest!)

Does this interact with Feather or some of the other ideas being bandied
about for 9.0?  I suspect so...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=360894&aid=219316&group_id=10894