[thelist] CFMX problem - HTML output cut off - and characterencoding

Steve Lewis nepolon at worlddomination.net
Wed Jul 16 15:29:17 CDT 2003


Joshua Olson wrote:

>From: "Jeff Howden" <jeff at jeffhowden.com>
>
>>fwiw, there are a few things like this in cfmx that i *really* don't like
>>because they break the semantics of some of the cf tags.
>>    
>>
>Semantics refers to the "meaning" of something, syntax refers to the rules
>you must follow when representing that meaning.  I find it very unlikely
>that cfmx changed what a tag does.
>  
>
I read Jeff's comment as the syntax rule (to allow expressions that lack 
an assignment (operator)) allows broken semantics.  Semantically, a 
cfset tag without an assignment occuring is an example of broken 
semantics.  Programming language syntax ought to constrain the semantic 
usage to remove ambiguity.

While the statement <cfset 1 + 1> is unambiguous, it also does not match 
the stated intention of the tag.  As Jeff pointed out, the intended 
semantic meaning of a cfset tag is that it "defines a ColdFusion 
variable. If the variable exists, this tag sets it to the specified 
value." We all agree that <cfset 1 + 1> does not mean what it was 
intended to mean in the documentation.  We all know what result we 
expect, and that is what we get, because we see the function as doing 
nothing because it is ... wait for it: semantically broken. :)

While it does not generate parse or run-time errors, Jeff and I agree 
that it is not our style.  It seems pretty obvious to me that cfset is 
not the intended place for such expressions as 1+1 and for execution of 
UDFs which do not return useful values.  The optimal place, in the eyes 
of the language designers, was the cfscript tag. 

Need another reason to consider appropriate coding style? Following 
intended style is a good way to ensure future compatibility.  I refer 
you to the debate over writing standards-compliant (X)HTML and CSS et 
al.  Substitute <cfset> for <table> in the discussions and we have seen 
it all before.

As for one more random comment, I believe that in most imperative 
languages the = (assignment operator) is in fact an operator, but a 
different class of operator (not a relational operator, numerical 
operator, boolean operator, etc) than we are used to thinking of.  I do 
not think this is an important point in the course of this discussion 
but I thought I would throw the thought out there in case anyone wants 
to look up exactly what Allaire called assignments, if not operators.

cheers,
Steve





More information about the thelist mailing list