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 stackingjbr - modify a proc's behavior with a shim
Is this sort of simillar to delegation in Snit's Not Incr Tcl?
