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]
