[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