Required arguments without a default? How often do you run across those? It seems to me that if you're declaring an argument, you'd always specify a default, because you want that variable to be there. Otherwise you'd just use an implicit argument and dereference it out of the arguments array/struct.
Not to say that's not a good reason for using the arguments scope, but it seems a strange position to put yourself in to begin with. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Stephen Milligan > Sent: Friday, March 19, 2004 2:48 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Unscoped references in CFSET within CFFUNCTION > > > > >Do you use the variables scope for something like "i" in all > >your page level CFML? If not, why is having local scoped > >variables be unscoped so terrible? > > > > > > I do if I think there's a chance a variable of the same or > similar name may > exist in an implict scope, or where there might otherwise be > confusion. > > Up until CFMX, the only implicit scope that you would > normally be putting > variables into directly was the VARIABLES scope. That meant > that you could > fairly safely work with unscoped variables because you knew > that VARIABLES > was the first implicit scope that got checked and given the > context of what > you were doing, probably what the variable names were likely > to be in the > other implicit scopes. > > Now you have CFCs which bring with them the combination of VARIABLES, > ARGUMENTS and un-named local scope. The first place that gets > checked is the > un-named local scope. If you have an argument that is not > required, you can > easily end up accessing a variable in the VARIABLES or some > other implicit > scope if you do not specify the 'arguments.' prefix. This can be > particularly awkward if you have a CFC that handles something > like form > validation. You will most likely have a variable in the form > scope that has > the same or similar name to one in the VARIABLES scope of the > CFC doing the > validation, and very possibly another one in the > ARGUMENTS/local un-named > scope of the specific method performing the validation. > > Depending on the complexity of the validation routine, you > may or may not > run a query against a database, and (heaven forbid) loop over > the query for > some reason or another. Now you have the local query scope to > worry about > too if you aren't scoping your variables. > > That and the fact that CFCs can be persisted across multiple > requests, and > have the ability to look up the implicit scopes makes it much > more important > that you scope all references to your variables now than in > versions prior > to CFMX. > > I wouldn't go as far as to say it's terrible, but it's mildly > unsettling if > you have to come in to load test or debug someone else's application. > > Spike > > ---------------------------------------------------------- > 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]
