OK. (dim light bulb begins to blink on, then off) So... <cfset var foo="" /> sets for life of method, <cfset variables.foo=""/> sets for life of CFC instance.
But isnt "this.foo" read/writable from outside of the instance -- <cfset object.FOO = "just buy-passed all of your checks"> while variable.FOO is only read/writable to methods of the instance? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Barney Boisvert Sent: Tuesday, March 16, 2004 12:43 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Variable Naming, WAS: RFC, CFC Best Practices You're dead on with the second paragraph. Arguments and variables declared with the 'var' keyword are the only ones that are specific to a single method call. Unscoped, 'this' scope and 'variables' scope (the default, and therefor where your 'instance' struct resides) all persist for the list of the CFC instance. Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Andy Ousterhout > Sent: Tuesday, March 16, 2004 10:35 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Variable Naming, WAS: RFC, CFC Best Practices > > Optional comment sort of mentions this, just doesn't make it > clear to an > amateur like me. Perhaps to the professionals out there your text is > crystal clear. If this is clear to the more experienced, > then your page > should to choose an audience, or make clear an already chosen one. > > Also, perhaps you could help me understand this better. I > don't refer to my > instance variables as "variables.instance.foo", just as plain > "instance.foo". I thought that "instance" was a qualifier > along the lines > of "variables" and "arguments". I thought that the difference between > variables and instance was that instance kept its life until > the object was > deleted while variables held their values only for the life > of the current > method call. It sounds like this is not the case and that > all variables > maintain their life for the life of the object and that all > references to > instance should be fully qualified as "variables.instance". > > Tell me it ain't so! > > Andy > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Nathan Dintenfass > Sent: Tuesday, March 16, 2004 12:17 PM > To: [EMAIL PROTECTED] > Subject: [CFCDev] Variable Naming, WAS: RFC, CFC Best Practices > > > Andy: > > You are correct that is the best practice for scoping -- > though, I thought > my document said the same thing ;) Can you let me know what > part of my doc > seemed to contradict that, so I can fix it? > > In regards to returning "THIS" From your init() method -- others have > pointed out the ability to do "chaining", but more > specifically it makes > your init() method mirror the behavior of calling "init()" on > a java object > instantiated in CFML (which is why we use the word "init" in the first > place). > > - Nathan > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of Andy Ousterhout > > Sent: Tuesday, March 16, 2004 5:23 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] RFC, CFC Best Practices > > > > > > Nathan, > > > > I thought the best practices for variable naming was: > > > > instance.foo Private data shared that needs to stay set > > for the life of > > the object > > var.foo Method-specific temporary variables > > required only during a single > > call of that method > > this.foo Publicly available data, which is > > discouraged. Can someone > > provide case when use of THIS is recommended? > > > > I do not understand returning "THIS" from the init? What purpose > > does this > > serve? > > > > Andy > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of Nathan Dintenfass > > Sent: Monday, March 15, 2004 10:38 PM > > To: [EMAIL PROTECTED] > > Subject: [CFCDev] RFC, CFC Best Practices > > > > > > I've noticed that many of the best practices talked about > on this list are > > not as widely known as I would have thought. What's worse, > most of the > > basic best practices related to CFCs are not well documented or are > > documented in disparate places. > > > > I'm trying to capture a concise list of CFC best practices > that everyone > > coding CFCs should be aware of (if not follow). > > > > Perhaps some of y'all have comments/additions/criticisms, which > > I'd welcome: > > > > http://www.dintenfass.com/cfcbestpractices/ > > > > ---------------------------------------------------------- > > 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] ---------------------------------------------------------- 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]
