Forum OpenACS Improvement Proposals (TIPs): Re: Enhance <multiple> to enable locally-aliased and implicit multirow reference styles.

i see the empty name as well skeptical. Having myself used the "empty array name" idiom in several places internally, i would rather plead for good and declarative names as "contract" between tcl-code programmer and adp-designer.

Similarly, i am wondering where the need for variable alias comes from. why don't you name the variables at first hand reasonably? it open more questions: what happens/should happen if the alias name shadows an existing variable name; or when one alias name is used for multiple vars, etc. Does the alias lead to better and easier understandable adp files? Just wondering and asking....


As a TCL programmer, I am naming the multirow variables very clearly and carefully. In complicated pages I am using long descriptive names for my multirows so it is clear to the designer what they contain. But the long descriptive names can obscure the visual structure of the ADP to the designer by creating a repeated pattern that does not convey useful information. This repeated information still takes up a lot of space. So a locally-defined aliased name becomes useful to remove the redundancy while maintaining minimal context. This helps reduce boiler-plate code and encourage concise expression of purpose.


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 ...? …)