#1970 rename traces follow renamed command

obsolete: 8.4b2
Don Porter
46. Traces (50)
Don Porter

As discussed on TCLCORE, execution traces
should attach to the commands themselves,
and rename and delete traces should attach
to command names. However:

% proc print args {puts $args}
% proc foo {} {}
% trace add command foo rename print
% rename foo bar
foo bar rename
% rename bar soom
bar soom rename

Clearly the "rename" trace attached to
the name "foo" was transferred to the
name "bar".

If that's not a bug, then we really need to
beef up the docs to explain just what
rules these command and command name
traces follow.

This is all related to Bug 565823 as well
as it indicates the lack of a clearly defined
and documented distinction between
commands and command names.


    • labels: 105682 --> 46. Traces
  • Don Porter
    Don Porter

    • assigned_to: msofer --> dgp
  • Will Duquette
    Will Duquette

    Logged In: YES

    I strongly disagree that rename and delete traces should attach to
    command names rather than commands. Snit uses a rename/delete
    trace to detect when a Snit instance is renamed or deleted...and if the
    Snit instance is renamed, the trace remains attached to the Snit instance
    under its new name, as it should. If myobj is the name of a Snit
    instance, then

    % mysnittype myobj
    % rename myobj hisobj
    % rename hisobj ""

    destroys the instance, as it should.

    In any event, the current behavior has been in place for the entire
    lifespan of Tcl 8.4. If you change it, it will break Snit badly, and I
    can't imagine that Snit's the only package affected.

    If the other behavior is really necessary, add it as

    % trace add commandname foo ....

  • Don Porter
    Don Porter

    Logged In: YES

    Very well. Snit is important, and snit
    depends on this, so I'm inclined to
    mark this "Won't Fix".

    Before I do, I hope you don't mind
    revisiting the issue with me though?
    Maybe we'll find a consistent way out.

    Looking back at this TCLCORE message...


    Is either of Model I or Model II described there
    compatible with the needs of Snit? (Based on your
    comments so far, I think I understand Model I
    won't work for you?)

    That message isn't a model of clarity, so if
    it helps to just state what Snit needs, that's
    fine too.

  • Don Porter
    Don Porter

    • status: open --> closed-invalid
  • Don Porter
    Don Porter

    Logged In: YES

    Withdrawing this.