#1970 rename traces follow renamed command

obsolete: 8.4b2
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.


  • Donal K. Fellows

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

    Don Porter - 2003-06-26
    • assigned_to: msofer --> dgp
  • Will Duquette

    Will Duquette - 2004-08-21

    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 - 2004-08-21

    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 - 2004-09-09
    • status: open --> closed-invalid
  • Don Porter

    Don Porter - 2004-09-09

    Logged In: YES

    Withdrawing this.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks