>       As I said earlier today when I was talking to someone, I
>       won't use
> any names:)  Sometimes you want to leave scope off of form
> and URL mainly
> for their use.  If they are referring to my code, they
> will notice that
> there is always scoping used on CGI, Cookie, session and a
> lot of other
> variables.  Do I normally avoid them, yes when writing
> form validation code
> so I don't have to type as much.  If I would do something
> as backwards as
> looping through an entire scope to reset one scope to
> another and claim it
> to be faster, who could possibly think that finding a work
> around to try and
> make your statement true would possibly be logical?

In earlier versions of Fusebox (or simply FB3 for earlier
versions of CF Server) there used to be a custom tag that
would copy all the variables from form and url into an
attributes structure one-by-one... which worked, but man is
it ugly... Not the code itself per-se -- it's just a fairly
normal loop with a single cfset statement, but the idea of
it, executing a custom tag and performing a loop in CF (a
high level language) and all the overhead involved. The
structappend() function was added between CF Server 4.5 and
4.5.1 which replaced the custom tag with 2-3 short, sweet
lines of code, and put all the looping in the low-level
p-code (now Java bytecode). Personally I think the function
itself is hideously underrated -- I rarely see it used
except in my own code.

>       And as many of you know, I also believe that if you say
> that you should 'always' do something in code, then you
are
> very narrow minded.  Do you think allowing none scoped
> variables in CF and ASP was an accident?  A bug?  Or are
you
> just smarter than the creators of these scripting
languages?

I dunno, I've designed a fair lot of code that I don't
(wouldn't?) use for myself. But I've designed it because I
see other people wanting to use it. Unscoped variables may
or may not have been a similar excercise for the authors of
various scripting languages.

I'd agree that "always" and "never" have to be used
sparingly, but there are cases in which I use them. Never
put <cfset = foo> in your code in CF5 and prior unless you
want to arbitrarily restart the server. :) Never use files
with a .xml extension to hold application critical
information (path info, dsn usernames and passwords, etc)
unless you want people to be able to see that info from a
standard web request or you know that any server you put the
app on will associate .xml with the ColdFusion server... For
that matter, never use .inc or any other extension for cfml
code (although they do parse properly in cf as long as the
base template is a .cfm) unless you want to confuse any
other developers who have to look at the code later and risk
the chance that someone will view your code in their browser
-- slim tho that risk may be.

>       Also, in the past I have created sites that have received
>       over 1
> million hits in one hour and currently work on a site that
> receives over 2
> million hits a day.  You work on sites that get 1000 hits
> a day if they are
> luck, more like 1000 a month.  In my mind, worrying about
> this kind of stuff
> is a waste of your time an your employers.  Code anyway
> you want.  I code my
> way, that I know works and have testing in live
> environments, not looping on
> beta code.  If you want to code your way that is fine, we
> don't even work
> together.
>       I cannot see the difference in load times from scoping
> or not scoping url or form variables, so you are right
> because you think you are?

When did this become a flame war? And didn't I mention that
before? :)

It's a fact that there is a (miniscule?) performance
difference between #form.var# and #var# ... though in most
cases you would probably have to use a legitimate
load-testing tool to see the difference and even then it
would be minute. It's a fact that there is a performance
difference because the machine must process a set of
instructions in order to search the hierarchy of scopes to
find the variable #var# whereas there is no searching, just
finding when you use #form.var#. So it's not a matter of
being right because we think we are -- it's an indisputable
fact that there is more for the machine to perform when the
variable is not scoped. You could say there's no performance
difference because the execution time doesn't change
noticeably -- but the code does in fact perform differently
whether you notice or not.

That being said I don't personaly scope for the sake of
performance. I never have. I scope for the sake of clarity.
That and the fact that certain scopes (attributes) can not
be referenced by an unscoped variable. I find it much easier
to read a new piece of someone else's code when the majority
of the variables are scoped. I find my own code easier to
read as well -- and -- it also eliminates the possibility of
unscoped local variables being accidentally or maliciously
supplanted by hand-mangled url variables.

> As you said this afternoon, you can loop through it 1
> million times and see
> a difference.  If you get 1 million hits in one second or
> less to a website
> you created, you will run out of threads before a single
> web server will be
> able to serve it an everyone will be waiting in line
> anyway.  In talking
> about speed, there is a lot more involved than scoping a
> variable.   Do any
> of the sites you have created or maintain get that many
> hits?  Are they on a
> single server or on multiple.  Mine is on a single server
> running CF 5.0.

> Jacob

> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf
> Of S.Isaac Dealey
> Sent: Thursday, September 18, 2003 5:55 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Since its so quiet lately . . .

> I was pretty slack about scoping variables when I first
> started working with
> ColdFusion and for a while I tried to leave form and url
> variables unscoped
> intentionally, although I've given up that habbit. I like
> to copy all my
> form and url variables into an attributes structure in the
> application.cfm
> which allows me to use base templates as custom tags if
> the need arises and
> it's only 3 short, sweet lines of code. (It's one of the
> nicer tricks from
> Fusebox) If you use New Atlanta's BlueDragon server it's
> only 2 lines of
> code because BlueDragon automatically combines the form
> and url variables,
> so referencing form[var] is the same as referencing
> url[var].

> I've mostly gotten out of the habbit of unscoped
> variables, and try even
> with the variables scope to scope them because sometimes
> when you don't
> scope them during a set statement they don't actually get
> into the variables
> scope, although I don't know how or why they don't. If I
> need a temp
> variable quickly for a loop or the like, I'll frequently
> use a single
> character variable like x or i unscoped, only if I know
> that I've set it and
> am making all references to it in the same template. And
> of course, if it's
> in a function or a CFC method, I always make sure to use
> <var> to declare
> the same single-character variables just in case.

> Is scoping one of the first things a cf developer should
> learn? Maybe. I
> think so. I know the question of scoping has sparked minor
> flame wars on the
> cf-talk list. Not by any means like the flame wars sparked
> by the issue of
> locking, but they've happened.


> s. isaac dealey                972-490-6624

> team macromedia volunteer
> http://www.macromedia.com/go/team

> chief architect, tapestry cms  http://products.turnkey.to

> onTap is open source           http://www.turnkey.to/ontap


>> Thought I would spark up a quick discussion.

>> I was discussing a few things with a coder (no names),
>> and I raised
>> the subject of scoping variables.

>> I am a real stickler when it comes to scoping variables.
>> Other than obvious
>> performance gain, and not having the issue of values
>> bleeding from one
>> scope into another - scoping simply makes code much
>> easier to read.

>> Looking at the variable #customer# tells you there is a
>> variable named
>> customer.  Looking at the variable #form.customer# or
>> #qInvoice.customer# tells you where the value came from
>> and some
>> insight on how it is going to be used, why, etc...
>> (Especially when
>> you deal with more than one page per
>> request)

>> I do on the other hand leave local scoped variables alone
>> (the
>> variables.[name] scope) - Which I think is standard
>> practice, and
>> there is no ambiguity when only one scope follows such a
>> convention.

>> I was curious if anyone else had a differing view of
>> scoping.  Perhaps
>> (though I highly doubt) someone can give me an example of
>> when leaving
>> off the scope of a variable name has an actual advantage.

>> The only idea that was half valid was using either
>> form/url scope.
>> This of course can be solved by coping one scope into the
>> other and
>> can be done in a few lines, so in the end, I don't think
>> it's much of
>> a valid point at all.

>> Am I alone in thinking scoping variables is an absolute
>> must, and
>> pretty much day one stuff?

>> Best Regards,

>> Nate Nielsen
>> [EMAIL PROTECTED]

>> -----------------------------------------------
>> To post, send email to [EMAIL PROTECTED] To unsubscribe:
>>    Send UNSUBSCRIBE to [EMAIL PROTECTED] To
>>    subscribe /
>> unsubscribe: http://www.dfwcfug.org





> -----------------------------------------------
> To post, send email to [EMAIL PROTECTED]
> To unsubscribe:
>    Send UNSUBSCRIBE to [EMAIL PROTECTED]
> To subscribe / unsubscribe: http://www.dfwcfug.org



> -----------------------------------------------
> To post, send email to [EMAIL PROTECTED]
> To unsubscribe:
>    Send UNSUBSCRIBE to [EMAIL PROTECTED]
> To subscribe / unsubscribe: http://www.dfwcfug.org



s. isaac dealey                972-490-6624

team macromedia volunteer
http://www.macromedia.com/go/team

chief architect, tapestry cms  http://products.turnkey.to

onTap is open source           http://www.turnkey.to/ontap


-----------------------------------------------
To post, send email to [EMAIL PROTECTED]
To unsubscribe: 
   Send UNSUBSCRIBE to [EMAIL PROTECTED]
To subscribe / unsubscribe: http://www.dfwcfug.org

Reply via email to