In the scenario I just gave, that is how I don't use scoping.
Writing it with scope would take one page to edit one to add or a lot of if
statements.  Yes, instead of coding extra amounts of code, I do not scope.
I think some of my techniques are advanced and learned over time, but I
could be wrong.  Perhaps I will start creating files called add.cfm,
update.cfm and delete.cfm like some people do.  Sure, if the client changes
anything (like they always do) it will take me twice as long to update the
code, but at least I saved them .00001 seconds!!!!
        The reason that this got so heated on the other lists is that some
people believe differently, and as I said in my response, that is fine.  I
have had to read other peoples code.  Fusebox, BroadVision, JS, webDNA, ASP,
PHP, VS, VB.  I have never hit the problem that you guys have with not being
able to find variables that are not scoped.  CTRL+F works for me.
        I also do not try to write OOP on code that is compiled/interpreted
at run time.  So you may have to look in one or two files to see variables
in my code, not 10 like under some FB implementations I have found.  If I
where writing spaghetti code like that, then I would definitely need scoping
on everything, heck, I'd probably name my variables insertDataFName where
insertData is the name of the .cfm file I am in.  But that is just me.
        I do not have trouble reading my code or anyone else's.  In my mind,
if you can't read someone's code, you don't really know that language that
well and you should read it, you will learn something.  Don't rewrite for
the sake of rewrite, learn from the code.  It may be something useless that
you learn, but you'll learn something.

Jacob

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of S.Isaac Dealey
Sent: Friday, September 19, 2003 12:45 AM
To: [EMAIL PROTECTED]
Subject: RE: Since its so quiet lately . . .

>       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



-----------------------------------------------
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