[thelist] CF: Error Trapping: Tip & RFC

Joshua OIson joshua at alphashop.net
Wed Jan 10 23:24:28 CST 2001


I found the speed difference between cfset and cfparam to be rather
appreciable.  I had about 10 cfparams in one tag (don't ask which one, I
don't remember), and found it significantly cut down on the tag execution
time, to about half what it was originally.  Since the purpose of the tag
was to set variables, I'd venture to guess that cfset is about twice as fast
as cfparam.

<tip type="cold fusion">
I discovered the other day (and I'm sure most people already know this) that
Cold Fusion has adopted a similar schema to js for variable reference.  If
you have lines such as the following in your code:

<cfset foo = Evaluate("form.myvar_#i#")>

because you are trying to set a variable based on a dynamic form element,
you can now replace it with the following:

<cfset foo=form["myvar_#i#"]>

and hence completely remove the Evaluate?
</tip>

I'm sure most everybody already knows that structs and arrays are basically
the same thing, but I never put 1 and 1 together until a few days ago.  So
now I've spent a little time rewriting Evaluates as I've come across them in
my code.

-joshua

----- Original Message -----
From: "jeff" <jeff at members.evolt.org>
To: <thelist at lists.evolt.org>
Sent: Wednesday, January 10, 2001 9:12 PM
Subject: RE: [thelist] CF: Error Trapping: Tip & RFC


> joshua,
>
> :~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> : From: Joshua OIson
> :
> : I think you might've missed my point.  The advise
> : was given in the original to use cfparam liberally
> : for error avoidance.  My point is, if you are given
> : the option to use either cfset or cfparam, go for
> : cfset.  You will encounter times when you *know*
> : that a variable is not set and it needs to be, like in
> : application.cfm, and times when you don't care
> : what it was before, but need it to be something
> : in particular right now..  I've seen variable cfparam'd
> : in there when you know without a doubt that this
> : is the first time a variable is being used.  So, go for
> : cfset, because it is faster, that's all.
> :~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> if speed is your primary concern, then yes i'd say you're right.  however,
> what kind of a speed penalty are we talking about for using a cfparam
> instead?  i'm sure it's hardly even measurable except in extreme
situations.
>
> personally, my preference is to use cfparam to set up variables and their
> defaults and use cfset *only* when i'm changing the value of a variable.
> that way when i come back and look at it later i know which action i
> intended the code to take based on whether i used cfparam or cfset.
>
> what can i say, i'll always argue readability and maintainability over
> performance any day (so long as the performance for that readability and
> maintainability isn't too great).
>
> :~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> : I'm not advocating isDefined, though I disagree with
> : your dogmatic stance on the issue... but we won't go there.
> :~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> don't worry.  i won't go there either.
>
> next thing on my list to picket?
>
> evaluate()
>
> ready?
>
> .jeff
>
> name://jeff.howden
> game://web.development
> http://www.evolt.org/
> mailto:jeff at members.evolt.org
>
>
> ---------------------------------------
> For unsubscribe and other options, including
> the Tip Harvester and archive of TheList go to:
> http://lists.evolt.org Workers of the Web, evolt !
>





More information about the thelist mailing list