I quit two years ago, that's why I'm so stressed! I was never stressed when I smoked.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Blackman Sent: Friday, September 19, 2003 9:54 AM To: [EMAIL PROTECTED] Subject: RE: Since its so quiet lately . . . I think you have a smoke with that coffee too...Whew! -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jacob Cameron Sent: Friday, September 19, 2003 9:32 AM To: [EMAIL PROTECTED] Subject: RE: Since its so quiet lately . . . Now, I'm going to have my coffee. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Blackman Sent: Friday, September 19, 2003 8:26 AM To: [EMAIL PROTECTED] Subject: RE: Since its so quiet lately . . . I just read another novel...Good Morning everyone, wake up and smell the coffee. Nice work Nate. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nate Nielsen Sent: Friday, September 19, 2003 1:18 AM To: [EMAIL PROTECTED] Subject: Re: Since its so quiet lately . . . Jacob, I was honestly looking for objective views on the subject. Stop taking everything so personally and attacking people. BUT since you want to, and in response . . . *evil grin* <cf_soapbox> "Do any of the sites you have created or maintain get that many hits?" : Yes. =) "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?" Write this down: <cfset request.form = structNew()><cfset request.form = structCopy(form)>. Not exactly looping over an entire scope, is it? Try not to prove your point with invalid or poor code theory, it reflects badly on yourself, not me. Regardless, I am of the belief that you can design an application without having to have access to both scopes as equal to make things "easier" on myself, you brought up the ideology of using them to accomplish the same - not me. Even if we decided that form and url "scoping is not a must." - I am of the belief that query scoping - is in fact, a "must" - which is an important point, because even those that my sway on the form and url issue, would likely believe that query scoping just plain makes sense. Your idea of outputting a variable : <cfoutput query="qMyQuery"> <cfset firstName = firstName> </cfoutput> <cfoutput> #firstName# </cfoutput> My idea of outputting a variable: <cfoutput> #qMyQuery.firstName# <cfoutput> I think in the above example, the statement <cfset firstName = firstName> says it all (a = a is plain ridiculous). First of all you are now creating a new memory space to duplicate effort. You have created a loop process to set the information, only to help CF understand what you are ~attempting~ to accomplish. You have required CF to search scopes 3 times, whereas mine did not search any. You are also making extra key strokes, which as you point out in your opinion, is an important consideration when coding. I cannot see any possible way for someone, or you, to defend that. *tongue in cheek* You work on a site that receives supposedly 2 million hits a day, which is boils down to closer to 200,000 page views per day, and last time I checked, that number is still a little inflated. One site though - big deal. You are seriously out of your league. To assume the only site I have worked on gets 1,000 hits per day or 1,000 a month "more like" is plain irresponsible on your part. On a personal note, my web work resume alone runs circles around yours (Coca-Cola,FedEx,American Airlines,The Sabre Group,Ernst & Young LLP,The Associates,GTE (Verizon now of course),AT&T,Nortel Networks,RealEstate.com,etc) so you might want to reconsider your position of "hits = knowledge" or you will win this argument for your opposing team real quick. Regardless- Some of the best developers I know work on internal applications, providing elegant solutions to complex business problems. I think it has no relation of ones knowledge in the matter. Bottom line is that : [1] scoping does effect performance. Having the server search for your variables for you, to save you typing a few letter is just plain lazy, or you just don't know any better (as we all didn't at one time of course). Yes, there are real-world impacts of this when you are dealing with values, not just looping over code a million times. If you have ever dealt with calling queries via structs and arrays, hefty query recursion with UDFs, used a complex stack storage method, used WDDX or XML for storage of scoped information, etc - you would know that 1ms per block of code can be the difference of 100s or 1000s of ms in the end. [2] scoping does effect code readability. The example of code above was taken from real-life, "production" code. When you reach a form that says value="#firstName#" - you have 6 pages for the request, plenty of queries (don't get me started,lol) - Where is the coder to look for the value of "firstName". Is it a value that was passed from a previous form submit? Is it a value that was set to a default? Is it a value passed in the URL? Is it a value from a query? Why should we suffer another developer to search for 5-10 minutes to save ourselves from typing "qMyQuery." in front of that value? I think a top priority and quantifiable value to a client is not only delivering code that squeezes every ounce of performance, reliability and function our of the serve - but also to keep one eye on extensibility. Wasting countless hours on re-coding or searching through spaghetti code is the most expensive risk that can be assessed because the ramifications are limitless. " In talking about speed, there is a lot more involved than scoping a variable." -I'll agree with you on that, but doesn't mean we shouldn't bother doing everything in our power to speed up our code - especially if we know better. That's like saying "you don't need to drink liquids, because more than that is involved in nutrition." Do we have to pick and choose to use our knowledge for only some things, when we know other are important as well? "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." Try these: Always comment your code, even if it be minimal. Always try to use joins before resorting to looping over queries for information. Always name your variables with meaningful names (username rather than var038475). Etc. Is it really fair to say that general rules and guidelines can't be placed while mainting an open mind? I think you can have both. *gasp* My simple question was, and still is - is there any excuse rather than laziness or lack of knowledge (we should all admit we've all been there too) that anyone can give me for not scoping variables? I've never heard one, and thought maybe someone here might be able to enlighten me. =) Regards, Nate Nielsen (also, if you want to continue to attack people, you will continue being attacked yourself. please take it off list if you can't handle this subject objectively.) ----- Original Message ----- From: "Jacob Cameron" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, September 18, 2003 6:27 PM 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? > I didn't say there was anything wrong with scoping, simply that I > don't do it on form and URL normally unless I am doing it for security > reasons. In my mind, scoping is not a must. A knowledge of its > existence in the world sure, but if I had my way. Everyone would > start learning to code > with ANSI C so they learn about scoping from that as I did. 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? 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? 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 > ----------------------------------------------- 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 ----------------------------------------------- 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
