OK, I want to make sure this is clear. I confused your initial email in that you had "var.foo" -- I assumed you meant variables initialized with the "var" keyword, not scoped as "variables".
The use of "instance" is not built into CF at all -- it is a convention that a lot of people have adopted for the reasons articulated in other emails on this thread and in my document. That said, there are some disagreements about whether it's OK to say "instance.foo" vs. "variables.instance.foo" -- I think of "instance" as a "virtual scope", so I create it in my init() method by saying <cfset variables.instance = structNew()>, but I then use it as "instance.foo" everywhere else. Others think it should always be scoped explicitly. But, scoping of "variables.instance" aside -- they both behave the same way as far as the lifecyle of a component -- they both live for the life of the instance and both are "private" instance data available to all methods inside the instance. You were thinking of <cfset var foo = "whatever"> for "local" variables that only live for the life of a single method call. VERY different from "variables.foo" -- and are not scoped when referenced. Hope this helps. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > 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]
