Forum OpenACS Development: Re: Logic change in "if" template tag in OpenACS 5.9

Collapse
Posted by Gustaf Neumann on
Dear Keith,

a larger compatibility with Tcl is desirable, but keep in mind that adp-eval is not the same as in Tcl, since we have there operators like "lt", "gt", "defined", "nil", ... and "true", where the latter is the same as a omitted operator (implementation wise). I don't think that we need all the tcl operators allowed in adp-if expressions (e.g. distinction between "==" ad "eq", etc.)

Also note that the tcl behavior is also sometimes strange, the following snippet

set a 1
set b 1.0
if { $a == $b } { lappend r "true" } {lappend r "false"}

set x 1
set y true
if { $x == $y } { lappend r "true" } {lappend r "false"}
if { $x } { lappend r "true" } {lappend r "false"}
if { $y } { lappend r "true" } {lappend r "false"}
returns "true false true true" (in the first case the "==" operator is true if the numeric values of the operands are the same, in the second example it is different).

Interestingly, if we look at the documentation [1], it does not mention the operator-less adp-if. In the (about 90) packages the adp-if is just used with boolean values (like '<if @moderate_p@>'). Tcl-compatibility is probably questionable either, when the value of the variable in the tcl-if is an empty string (Tcl raises an error here). Maybe raising an error here would be good.... In your example, the clearest notation would be probably "<if @myvar@ ne 0>".

Anyhow, can you please submit a bug on the issue tracker.

Many thanks
-g

[1] https://openacs.org/doc/acs-templating/tagref/if

Collapse
Posted by Keith Paskett on
Thanks for the additional perspective. We have 70+ packages that expect the <if @anyvar_p@> or <if @anyvar_p@> to evaluate true for any non-zero integer. In the short-term we will patch OpenACS 5.9 back to the 5.8 behavior. If the community has a compelling need to have integers other than 1 return false, we will probably eventually update our packages to work with the new tag behavior to minimize the number of core customizations we have to maintain across updates. We will submit a bug and patch.