I've seen some people just do: <cfset var local = structNew()>
I tried that for a while, but got really sick of stuff like: For(local.i = 1; local.i LT arrayLen(arguments.foo); local.i = local.i + 1) Do you use the variables scope for something like "i" in all your page level CFML? If not, why is having local scoped variables be unscoped so terrible? > From: "Stephen Milligan" <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Date: Fri, 19 Mar 2004 14:13:30 -0800 > To: <[EMAIL PROTECTED]> > Subject: RE: [CFCDev] Unscoped references in CFSET within CFFUNCTION > > >> If you prefix everything except local variables (including >> arguments), you won't have this problem. That's another way >> to tell what's local: it lacks a scope qualifier. >> > > Yes, that works well the first time you write a piece of code, but if you > have to later go back and refactor it for some reason you can easily leave > an unscoped reference to a local variable or argument that shouldn't exist > any more, but does exist in one of the implicit CF search scopes. That could > be a hell of a bug to try to track down. > > I'm strongly in favour of always scoping variable references for exactly > that reason, but given that you can't do that with the function local scope > it's hard to know what the best approach is in the long term. > > The only possibilities I can think of are: > > 1. Put all local function variables in the arguments scope and always scope > the references as arguments.x . > 2. Use getPageContext().getLocalFunctionActiveScope() to get a copy of the > local function active scope, then give that a name such as 'local' that you > can use in your code as a pseudo scope name. > > I don't like 1 because the ARGUMENTS scope is something that is passed in. > It just doesn't seem right to be modify the values in there any more than it > seems right to put modify FORM,URL or ATTRIBUTES scopes directly. Mostly > because you no longer have any way of knowing what was passed in and what > was manually added. In some cases that is an important distinction to be > able to make. > > I don't like 2 because it uses undocumented features of the > coldfusion.runtime.NeoPageContext class. Since they're undocumented they may > change in future releases, so you could potentially have to do a major > rewrite before any upgrades to the server. > > My gut feeling is that the safest option would be 1, but I still don't like > it. > > my 2c > > Spike > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' > in the message of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported > by Mindtool, Corporation (www.mindtool.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[EMAIL PROTECTED] > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
