Barney, I remember reading an earlier post that recommended never changing an argument's value, but if necessary, then save to a var scoped variable. I believe the view was that this made the overall code much more readable and simplified debugging.
1. Do you subscribe to this belief/coding style? Why/why not. 2. If you do follow this, then their would be a readability advantage to fully scoping arguments. Andy -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Barney Boisvert Sent: Friday, March 19, 2004 11:03 AM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Unscoped references in CFSET within CFFUNCTION Sean wrote: > On the contrary, if you declare something with <cfargument> > you should > explicitly qualify it with arguments. in every single place > you use it. "Arguments are local variables, treat them as such" is a perfectly legit way to look at things, you said so yourself, at least on 6.1. Why complicate the matter of scoping by adding what is effectivly an extra, unneeded scope to the mix? Yes, if you've got code from the 6.0 days, it's using the arguments scope already so that stuff works, but I've also go code from 4.5 hanging around that #evaluate(var + 3)# to output stuff. Doesn't mean I'd ever recommend that practice. I don't know about other families of languages, but the C-derived languages don't make the local/parameter distinction, and I've never heard anyone complain. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sean A Corfield > Sent: Thursday, March 18, 2004 10:39 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Unscoped references in CFSET within CFFUNCTION > > On Mar 18, 2004, at 1:15 PM, Barney Boisvert wrote: > > 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 > > Or rather, the contents of the arguments scope are copied into the > local scope at the start of the function - which is done to preserve > old code (CFMX6.0) that referenced arguments without a scope > qualifier. > > > <cffunction name="method" returntype="string"> > > <cfargument name="arg1" type="String"> > > arg1 copied to local scope as if you had: > > <cfset var arg1 = arguments.arg1> > > > <cfset arguments.arg1 = encrypt(arg1, "x")> > > This mixes scope qualifications (arguments. on left, unscoped > on right > - lookup finds local var arg1). > > > <cfset arg2 = encrypt(arg1, "x")> > > This sets arg2 in the unnamed (variables) scope from the > local var arg1. > > > <cfreturn arg1> > > This returns the local var arg1. > > > </cffunction> > > > > <cffunction name="method" returntype="string"> > > <cfargument name="arg1" type="String"> > > <cfset var arg1 = arguments.arg1> > > > <cfset arg1 = encrypt(arg1, "x")> > > Overwrite local var arg1. > > > <cfset arg2 = encrypt(arg1, "x")> > > Create (variables) scope arg2. > > > <cfreturn arguments.arg1> > > Return original arguments.arg1 (untouched) > > > </cffunction> > > > > <cffunction name="method" returntype="string"> > > <cfargument name="arg1" type="String"> > > <cfset var arg1 = arguments.arg1> > > > <cfset arguments.arg1 = encrypt(arg1, "x")> > > Overwrite original arguments.arg1 (with encrypted local var arg1). > > > <cfset arg2 = encrypt(arg1, "x")> > > Create variables.arg2 (as encrypted local var arg1). > > > <cfreturn arguments.arg1> > > Return now-encrypted arguments.arg1. > > > </cffunction> > > > > INHO, you should NEVER use the 'arguments' scope, as it's a > huge bunch > > of > > nastiness all around. > > On the contrary, if you declare something with <cfargument> > you should > explicitly qualify it with arguments. in every single place > you use it. > > The behavior you are seeing helps CFMX6.1 not break sloppy code that > worked in CFMX6.0 (which didn't have a local var scope). > > As long as you are totally consistent (either always use > arguments.foo > or always use plain foo for an argument), you will not see anything > strange. > > The other option would have been to break 'old' CFMX6.0 code... > > Regards, > Sean > > ---------------------------------------------------------- > 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]
