Updated 2012-01-11 11:50:16 by jbr

Conversation on the wiki
 suchenwi        Don (when you're back from |O|): you once showed me a trick of renaming commands into one's namespace, so one could have such "overloading" in cascades... but I forgot how you did it. Can you remember?
 Tomorrow        is "renaming commands into one's namespace" different from [interp alias] ?
 suchenwi        [interp alias] adds an additional way to call a command; renaming it makes it possible to substitute an overloaded version.
 suchenwi        E.g. (very simple): rename set _set; proc set {name value} {upvar 1 $name var; puts "$name<-$value"; _set var $value}
 kennykb Richard: Are you talking about the trick that Don uses in the ::control::assert package in tcllib?
 suchenwi        which logs every assignment to stdout, in addition to doing it.
 Tomorrow        oh. is that more complicated than generating a unique random number and renaming the command to cmd_number and telling your new command what the old version's name is?
 suchenwi        Could be.. I haven't looked at that, but will now.
 suchenwi        Tomorrow: now that too is an interesting idea, which would allow a "chain of responsibility"...
 Tomorrow        hmm. yeah, it's slightly more complicated. because while each piece knows what the next step is, if you want to remove links in middle of the chain then each piece needs to know at all times what its own current name is even when another item is stacked on top, or you need and external agency keeping track instead.
 suchenwi        The current name is easily found at runtime: [lindex [info level 0] 0].
 Tomorrow        so, you'd have a "stack foo onto set", which would rename set to set_original_<rnd>, make an internal note that it's now managing set, and create a new [set] proc that calls foo with $args. foo, when finished processing, would call [stack nextstep] to get the name of the procedure to chain to...
 Tomorrow        any time a procedure wants to remove itself from the stack, it would call [stack unregister foo from set]...
 suchenwi        Hmm.. interesting concept of autonomy - a procedure that removes itself from a stack.. :)
 Tomorrow        well, you could have the [stack register foo onto set] return a cookie that can be passed to [stack unregister], if you like...
 suchenwi        Hold it - my head is spinning...
 Tomorrow        heh, and you could probably even proritize things. [stack register foo onto set as FIRST], so that when you register other procedures onto the [set] stack,. [foo] will still stay at the top of the stack.
 aku     stacking commands -> Paul Duffin's code had something like that, possibly using tricks with Tcl_Obj types
 Tomorrow        actually, a cookie might be useful for the [stack nextstep] as well. so a procedure can be stacked onto multiple commands... [stack nextstep $cookie], returns a {cmd cookie} list, which you lappend the rest of your arguments onto and eval, so the current procedures cookie will always be its first argument when called, and [stack cmd name $cookie] will tell you what command you are currently pretending to be, as well.
 Tomorrow        so I could do something like:
        proc debug {cookie args} {
          set cmd [stack cmdname $cookie]
          puts "DEBUG: $cmd [join $args]"
          eval [linsert $args 0 [stack nextstep $cookie]]
        }
 Tomorrow        and then for all commands I want to watch, stack register debug on command
 Tomorrow        and using cookies like that, you could register a proc into the same command's stack multiple times, though I dunno why you'd want to do that.
 suchenwi        Interesting.. but I'm getting pretty tired now, sorry I can't follow you. Would you mind turning this into a Wiki page, for persistence?
 Tomorrow        hmm. for the last step in the stack, [stack nextstep $cookie] would have to return the name of a wrapper that discarded the cookie and called the real command, so that's not completely efficient.
 suchenwi        http://wiki.tcl.tk/3144 still has an (unclaimed) invitation to write about stacking commands.
 Tomorrow        sure, I can paste this conversation into there, so you can make sense of it later, no problem.
 suchenwi        Best set up a page titled [Stacking commands], so it's easily found and remembered.
 * dgp gonna assume RS got what he needed from that conversation.
 suchenwi        Certainly - (no namespaces though...)
 suchenwi        There is a question  by NEM on http://wiki.tcl.tk/2339 on multi-link "chains of responsibilities".

Larry Smith check out stacking

jbr - modify a proc's behavior with a shim

Is this sort of simillar to delegation in Snit's Not Incr Tcl?