Gustaf,
Sorry, I forgot to respond to your other questions:
"… what happens/should happen if the alias name shadows an existing variable name[?]; or when one alias name is used for multiple vars[?] …"
I'm not sure what you are referring to by the second question. Can you please elaborate on it?
The rest of the post will deal with your first question.
While I am sympathetic to your concerns (the prospect of silently-clobbered and shadowed variables give me mental itch!), I think shadowing variables is an acceptable outcome here. OpenACS does not make heroic efforts to protect the programmer from shadowing (or even clobbering) their variables. For a long time db_multirow
has silently over-written variables when it might have shadowed them instead. Consequently I feel it is slightly unfair to pick on this change for clobbering a variable that happens to be named the same as the alias.
The patch under discussion does not address clobbering of existing variables that match the name of the alias or the empty-name. It may be worth addressing this by making the alias-name shadow the existing variable as is done earlier in the code generated by the same template_tag
proc:
if {\[info exists $name\]} {
upvar 0 $name __${tag_id}_swap
}
…
if {\[info exists __${tag_id}_swap\]} {
upvar 0 __${tag_id}_swap $name
}
Considering this is a problem that shows up at least 3 times, it might be worth implementing a small TCL API that is similar to upvar
that will shadow existing variables rather that clobbering them. Perhaps they could be called pushvar
and popvar
and have the same signature as upvar
(… ?level? otherVar myVar ?otherVar myVar ...?
…)
--------
regards,
Andy