Thanks. I just caught on about what you said earlier that there is NO scope of arguments. That <cfargument> is like <cfparam>.
Thanks. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Barney Boisvert Sent: Friday, March 19, 2004 12:37 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Unscoped references in CFSET within CFFUNCTION Just to be clear, this is a pure-opinion post in response to a specific question set. > 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. First, people should consider the 'arguments' scope a depricated carryover from 6.0 that was required to not break code, but should NEVER be used. In 6.0 there wasn't a local variables scope, so any guidelines that went along with the 'arguments' scope can't be applied to 6.1 where there is a local variables scope. In other words, 6.0 arguments and 6.1 arguments are effectively two completely different things. With that statement, it becomes apparent that using the 'arguments' scope for ANYTHING with 6.1 is a bad idea. Function/method arguments are nothing more than local variables that get declared and prepopulated for you. If you need to keep an original copy, then make a copy. But never use the arguments scope to help you. For example, here is a simple (and poor) implementation of a function that checks whether a number is an integer: <cffunction name="isInt" returntype="boolean"> <cfargument name="num" type="numeric" /> <cfset var num_orig = num /> <cfset num = int(num) /> <cfreturn num EQ num_orig /> </cffunction> You could certainly do it the other way, leaving the argument intact, and changing a copy of the value: <cffunction name="isInt" returntype="boolean"> <cfargument name="num" type="numeric" /> <cfset var chopped_num = int(num) /> <cfreturn num EQ chopped_num /> </cffunction> Either of those is fine with me. On the other hand, this next implementation, along with multiple variations of the theme, is pure satan in my book (though just as functional): <cffunction name="isInt" returntype="boolean"> <cfargument name="num" type="numeric" /> <cfset var num = int(num) /> <cfreturn num EQ arguments.num /> </cffunction> So to answer your question, yes I do subscribe to the belief that arguments should never be written, but only under the condition that they are never read either. Simplicity is almost always better, and adding an extra scope in there for no benefit only increases complexity. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Andy Ousterhout > Sent: Friday, March 19, 2004 9:43 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Unscoped references in CFSET within CFFUNCTION > > 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] > ---------------------------------------------------------- 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]
