Well, I agree in principle, but the problem is that you can't explicitly
declare that you want to reference the local variable scope, so you're left
with a bit of inconsistency.
eg.
<cffunction name="loadConfigFile">
<cfargument name="filepath" type="string" required="true">
<cfset var configFile = "">
<cfset var configData = structNew()>
<cfif fileExists(filepath)>
<cffile action="read" file="#arguments.filepath#"
variable="configFile">
</cfif>
<cfif isWDDX(configFile)>
<cfwddx action="wddx2cfml" input="#configFile#"
output="configData">
</cfif>
<cfreturn configData>
</cffunction>
You can't scope the references to the configFile or configData local
variables.
Now let's say this application goes through several modifications and
changes and someone decides that you should be able to specify the config
file as a separate argument and that the filepath argument should just
contain the directory to the config file.
Now there's a potential problem if the new argument is called configFile.
There is no way to stop that argument being copied into the local un-named
scope, and no easy way to be certain that somewhere in the code you haven't
got some explicit references to the configFile variable in the arguments
scope, and some other revferences to the configFile variable in the local
un-named scope.
In the example above it would be easy enough to inspect the code and try to
make sure it was bug free, but there are a lot of situations where the code
in the function is much more complex.
That's where I see this being more than just an idle curiosity.
Put simply, it would be far too easy to accidentally forget to stick an
'arguments.' in front of a variable read or write when modifying existing
code.
As it stands, I don't see any solution other than undocumented hacks like
this:
<cfset var local = getPageContext().getActiveFunctionLocalScope()>
<cfset structDelete(local,'arguments')>
That way you can crate your own pseudo local scope and use it to prefix all
references to local variables, but it seems like a horrible hack to me
(Note, I haven't even checked to see if that would actually work).
Barney's suggestion to never reference the arguments scope is least likely
to cause the type of bugs mentioned above, but I just don't like the fact
that if you haven't passed the argument, and haven't declared the local
variable ColdFusion will search it's implicit scopes looking for the
variable which could lead to all sorts of weirdness.
Spike
>-----Original Message-----
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of Nolan Erck
>Sent: Friday, March 19, 2004 11:54 AM
>To: [EMAIL PROTECTED]
>Subject: RE: [CFCDev] Unscoped references in CFSET within CFFUNCTION
>
>Am I the only one who sees this thread/problem as a non-issue
>if you just always always always scope your variables (which
>is recommended practice by Macromedia anyway)?
>
>I mean, yes it's interesting and good to know of the
>underlying behaviors of CF, how things are copied to the local
>scope, etc. But if you're concerned about "foo" being
>"arguments.foo" or not, just put "arguments." in front and be
>done with it.
>
>Right?
>
>----------------------------------------------------------
>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]
