RE: [CFCDev] Functions local scope

[Roland Collins]

The problem with the “local = StructNew()” method is there are times when it can cause problems.  Take this code for example:   <cffunction name=”addNumbers” result=”numeric”>             <cfargument name=”num1” type=”numeric”> <cfargument name=”num2” type=”numeric”>                         <cfset var local = StructNew()>                         <cfset local.result = num1 + num2>               <cfreturn local.result> </cffunction>   Now yes, this is contrived, and I know I could return the result directly – it’s just for the sake of the example.  Now pretend you have some code that calls this in a loop:   <cfloop from=”1” to=”100000” index=”i”>             <cfset mySum = addNumbers(i, 100)> </cfloop>   Well guess what – you just added the overhead of 100,000 unnecessary object creations.  You’ve also added 100,000 StructInsert() calls (the cfset local.result statement does it implicitly).  Not only does this directly hurt the performance of the code, it also affects the underlying server processes.  That’s now 100,000 additional structs that have to be Garbage Collected!!!   Anyway, in this case, you obviously would never want to use the local = StructNew() method, and I run into too many other examples of this type of code that make it undesirable to use.  Not to mention I _like_ seeing all of my variables declared up front.   /.02   Roland   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Kotek Sent: Friday, July 08, 2005 11:49 AM To: CFCDev@cfczone.org Subject: Re: [CFCDev] Functions local scope   Everyone has their opinion. I'm on the other side of the fence, and think using a var-scoped local struct is much preferred. I think using "local" results in much less typing overall (you'd have to type "local" a whole lot of times to end up typing more than you would when declaring 10 separate var-scoped  variables). It also makes your method quite a bit shorter (I'm a fan of small methods). But more importantly, it is totally clear: this variable IS var-scoped...no question. When you don't provide a scope, you can't be totally sure...is this var-scoped, or is it one I missed and is this really variables scoped? I'm a big "scope everything" advocate, and creating my own local scope lets me keep to this practice even inside a method. So while I agree that using a $ or using "var" as the var-scoped struct is definitely not a good idea, the idea of creating a local "scope" of your own is, IMHO, a very good idea. :-) On 7/7/05, Jared Rypka-Hauer - CMG, LLC <[EMAIL PROTECTED]> wrote: Or, that is, using a var-scoped struct as a function-local container inside a cffunction tag... Sorry, I hate typos! J On 7/7/05, Jared Rypka-Hauer - CMG, LLC < [EMAIL PROTECTED]> wrote: Hey Barney... I'd say that it's because of CF's innate typelessness... since it sees all values, basically (and oversimplified), as a string, we can pretty well assume that the parser isn't coded to view "$" as a symbol of any kind. In other worse, since it's not specifically marked as a reserved symbol, it's not going to throw an error in the parser. I, personally, don't like it either... it reminds me of variables in the old Commodore 64 code... it was a marker of a certain type that I can't recall now since the last time I used it was 20 years ago. But, $myVar was different than myVar, somehow. In any case, I really don't like the idea of the var-scoped struct for all local variables inside a struct. I vastly prefer a series of var-local declarations at the top of my functions. It's cleaner, elminates a whole lot of extra stringage later in the function, it makes the whole deal a LOT more readable, and it's in keeping with normal coding practices outside the cffunction tag. So... I don't like it. :) Sorry Paul... I don't like it at all. Not that this means you SHOULDN'T use it... except that once the CF team at MM finds out that the parser needs to catch currency symbols as non-alpha characters all the code you've based on this will most likely break. Bad idea. Laterz, J -- --------------- ------------------------------------- Buy SQLSurveyor! http://www.web-relevant.com/sqlsurveyor Never make your developers open Enterprise Manager again. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone ( www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org