Now if the damn light will only stay on..... -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Nolan Erck Sent: Tuesday, March 16, 2004 2:08 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Returing "THIS" from init(), WAS: RFC, CFC Best Practices
Thanks Stacy and Nathan - those were incredibly helpful. -----Original Message----- From: Stacy Young [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 11:47 AM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Returing "THIS" from init(), WAS: RFC, CFC Best Practices Another way of explaining it is that it avoids you having to do this: <cfset x = CreateObject("component","foo") /> <cfset x.init() /> Instead you can 'method chain' in one shot: <cfset x = CreateObject("component","foo").init() /> The init is returning a 'handle' or reference to the component itself. -Stace -----Original Message----- From: Nathan Dintenfass [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 16, 2004 2:42 PM To: [EMAIL PROTECTED] Subject: [CFCDev] Returing "THIS" from init(), WAS: RFC, CFC Best Practices The reason you return "THIS" is that it mimics what createObject() does in the first place, which is basically to give you a reference to the public scope of the instance of the CFC. In other words, when you say: foo = createObject("component","Foo") you get an instance of foo -- but, only the public scope of it. Thus, if you return THIS from init and then do: foo = createObject("component","Foo").init() You end up with the same thing. This is also essentially what calling init() on a java object created in CFML does, so it maintains consistency in that regard too. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Nolan Erck > Sent: Tuesday, March 16, 2004 11:04 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Variable Naming, WAS: RFC, CFC Best Practices > > > That's what I've been told as well. Which is why I've never > understood why the best practice for init() is to "return this". > That scope sounds too broad, imho, since this is more of a > "global" scope. Maybe my lightbulb is still off. > > > > -----Original Message----- > From: Andy Ousterhout [mailto:[EMAIL PROTECTED] > Sent: Tuesday, March 16, 2004 10:57 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Variable Naming, WAS: RFC, CFC Best Practices > > > 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] ---------------------------------------------------------- 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]
