Yeah, I guess I'll just have to make sure I'm on any future betas and submit a bug if they do decide to change the way it works ;)
Spike >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Paul Kenney >Sent: Thursday, March 18, 2004 3:13 PM >To: [EMAIL PROTECTED] >Subject: RE: [CFCDev] Unscoped references in CFSET within CFFUNCTION > >Spike, > >I would be weary of doing that though... Like you said, who >knows why they did it that way -- and who knows when or why >they might change their mind. >Kind of cool though. > >Paul Kenney >WebMaster, CorporateWarriors.com >916-663-1963 > > >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Stephen Milligan >Sent: Thursday, March 18, 2004 2:23 PM >To: [EMAIL PROTECTED] >Subject: RE: [CFCDev] Unscoped references in CFSET within CFFUNCTION > > >I just did a bit of digging with getPageContext() and it looks >like CF creates a copy of the arguments scope in the local >unnamed scope rather than the other way around. > >Why they need to put a copy of the arguments scope in the >function local scope is open to conjecture, but I wouldn't be >surprised if it was so that backward compatibility wouldn't be >broken when people upgraded from 6.0 to 6.1. > >I think this snippet shows pretty much what's happening. > ><cffunction name="foo"> > <cfargument name="arg1" default="1"> > <cfset var arg2 = 2> > <cfdump var="#getPageContext().getActiveFunctionLocalScope()#" >label="before setting arg1" /> > <cfset arg1 = 3> > <cfdump var="#getPageContext().getActiveFunctionLocalScope()#" >label="after setting arg1" /> > <cfreturn> ></cffunction> > ><cfset foo()> > >This is kinda weird, but also kinda interesting because it >means you can change the value of an argument to a function if >required by manipulating the function local scope value, but >you can still find out what the initial value was by accessing >it as arguments.x. That may not be a common thing to do, but >it's useful to know you can. > >Spike > > >>-----Original Message----- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] On Behalf Of Barney Boisvert >>Sent: Thursday, March 18, 2004 1:15 PM >>To: [EMAIL PROTECTED] >>Subject: RE: [CFCDev] Unscoped references in CFSET within CFFUNCTION >> >>The answers make sense, it's actually CF that's bizarre. >What happens >>here? >> >> <cffunction name="method" returntype="string"> >> <cfset var temp = "1" /> >> <cfset temp = "5" /> >> <cfreturn temp /> >> </cffunction> >> >>Surely this shouldn't set the 'temp' var in the variables >scope in the >>second CFSET and then return 1, right? It'll return 5, as intended. >>Why do arguments work the same way? >> >>The arguments scope and local scope are the same. The 'arguments' >>struct (which you can reference by name) is actually a _copy_ of the >>local scope made after the CFARGUMENT tags, before any other tags >>(specifical local var declarations). CFARGUMENT is actually pretty >>much the same as using the 'var' keyword, except it allow sthe caller >>of the method to supply a value (or use a default). It's >actually the >>'argument' scope (not arguments >>themselves) that's quite bizarre. >> >>Take these three functions: >> >> <cffunction name="method" returntype="string"> >> <cfargument name="arg1" type="String"> >> <cfset arguments.arg1 = encrypt(arg1, "x")> >> <cfset arg2 = encrypt(arg1, "x")> >> <cfreturn arg1> >> </cffunction> >> >> <cffunction name="method" returntype="string"> >> <cfargument name="arg1" type="String"> >> <cfset arg1 = encrypt(arg1, "x")> >> <cfset arg2 = encrypt(arg1, "x")> >> <cfreturn arguments.arg1> >> </cffunction> >> >> <cffunction name="method" returntype="string"> >> <cfargument name="arg1" type="String"> >> <cfset arguments.arg1 = encrypt(arg1, "x")> >> <cfset arg2 = encrypt(arg1, "x")> >> <cfreturn arguments.arg1> >> </cffunction> >> >>The first will return the unencrypted string (because you're only >>setting the copy of arg1 in the arguments scope, not in the local >>scope). The second will return unencrypted (because you're >reading the >>copy of arg1 in the arguments scope). The third will return >encrypted. >>In the third, >>arguments.arg1 and arg2 will be the same at the end of the method >>(because the setting of arg2 uses the local copy of arg1, not the >>version in the arguments scope, which is encrypted). >> >>INHO, you should NEVER use the 'arguments' scope, as it's a >huge bunch >>of nastiness all around. >> >>Cheers, >>barneyb >> >>> -----Original Message----- >>> From: [EMAIL PROTECTED] >>> [mailto:[EMAIL PROTECTED] On Behalf Of Vince Bonfanti >>> Sent: Thursday, March 18, 2004 12:53 PM >>> To: [EMAIL PROTECTED] >>> Subject: [CFCDev] Unscoped references in CFSET within CFFUNCTION >>> >>> OK, here are some technical questions. Consider the following code: >>> >>> <cffunction name="method" returntype="string"> >>> <cfargument name="arg1" type="String"> >>> <cfset arg1 = encrypt(arg1, "x")> >>> <cfset arg2 = encrypt(arg1, "x")> >>> <cfreturn arg1> >>> </cffunction> >>> >>> Questions are: >>> >>> 1. In which scope is arg1 created by CFSET? >>> (a) function local scope >>> (b) variables scope >>> (c) neither, it overwrites arguments.arg1 >>> >>> 2. In which scope is arg2 created by CFSET? >>> (a) function local scope >>> (b) variables scope >>> (c) neither, it overwrites arguments.arg1 >>> >>> 3. What value is returned by this function? >>> (a) the original value of arg1 as passed into the function >>> (b) the encrypted value of arg1 >>> >>> The answers on CFMX 6.1 are: 1(a), 2(b), and 3(b). Isn't this odd? >>> Since the CFSET doesn't use the "var" keyword, shouldn't arg1 be >>> created in the variables scope (as arg2 is), not the local scope? >>> >>> And, since arguments scope takes precedence over variables >>scope when >>> searching for unscoped variables, shouldn't answer 3(a) be >>correct (if >>> we agree that arg1 should be created in the variables scope)? >>> >>> Now for a bonus question. Consider the following code: >>> >>> <cffunction name="method" returntype="string"> >>> <cfargument name="arg1" type="String"> >>> <cfset var arg1 = encrypt(arg1, "x")> >>> <cfreturn arg1> >>> </cffunction> >>> >>> Here's the question: >>> >>> 4. In which scope is arg1 created by CFSET? >>> (a) function local scope >>> (b) variables scope >>> (c) neither, it throws an exception >>> >>> The answer is: 4(c). But if it's illegal to explicitly create a >>> variable in the local scope that has the same name as an argument, >>> then why does CFMX do it implicitly in the first code example? >>> >>> Is this behavior deliberate? Is it a side-effect? Is it a bug? >>> >>> Vince >>> >>> >>> >>> >>> >>> >>> >>> ---------------------------------------------------------- >>> 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] > >---------------------------------------------------------- >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] ---------------------------------------------------------- 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]
