The issue is that there needed to be some scope for instance data, and the Variables scope was (unfortunately, it could be argued) the obvious choice for the very reason you are talking about -- it's consistent with the rest of CFML.
Since there needs to be some way to differentiate between local variables and instance variables we have the current situation. It might have made sense to create a new scope for local variables, but the Variables scope would not have worked because of the way it works in all other CFML settings (for instance, you can make UDFs on any CFML page that access the "Variables" scope -- and it will always be a non-local [to the function] variable). In my example of using "local" I used the var prefix, so no -- you would not need to worry about it polluting any other variables in your CFC since it would be local to the method and created each time the method is called. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Bryan F. Hogan > Sent: Monday, October 06, 2003 8:28 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Variable referencing in CFCs > > > "The thing is that variables declared with "var" don't exist in any named > scope." > > It may not, but I think it should be in the Variables scope. Just like: > > <cfset thisTest=1> > <cfoutput>#Variables.thisTest#</cfoutput> > > works in regular CFML pages. > > "You can then use local.foo for all your local variables, which would make > it > unambiguous when reading the code." > > Then you have to worry about closing your local scope after every > function, > correct? Since now the local scope is global throughout the CFC. > > "Generally speaking, when I'm reading CFC code I assume that if > the variable > doesn't have a scope it is a local variable -- one of the many reasons you > should always scope your Arguments and Variables variables." > > I agree 100%, just thought it should be extended to the variables also. In > my regular CFML code, I reference everything with their scopes, no matter > what it is. I also suggest to anyone else that they do that also. I like > setting my regular variables without the scope prefix but when > reading from > those variables I like using the variables prefix. But I can't do > that with > var scoped variables within a CFC. Which IMO stinks. > > Thanks for your reply > > Bryan > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Nathan Dintenfass > Sent: Monday, October 06, 2003 11:21 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Variable referencing in CFCs > > > The thing is that variables declared with "var" don't exist in any named > scope. That convention in CFCs is totally consistent with the way the var > keyword has worked since the introduction of UDFs in CF5. A function on a > page is another level below the "page" -- so, I think it is, in fact, > consistent with the way the rest of CF works (especially now that the > Variables scope works in 6.1). > > Since local variables are resolved first, there is no "searching up the > scopes" for local variables, so there should not be performance > implications. > > One convention I've seen, if you really want a "scope" when > reading the code > is to do something like: > > <cffunction> > <cfset var local = structNew()> > </cffunction> > > You can then use local.foo for all your local variables, which > would make it > unambiguous when reading the code. I find, though, that it becomes > cumbersome to do things like: > > for(local.i = 1; local.i LTE arrayLen(foo); local.i = local.i + 1){} > > Generally speaking, when I'm reading CFC code I assume that if > the variable > doesn't have a scope it is a local variable -- one of the many reasons you > should always scope your Arguments and Variables variables. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word '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]
