I must have missed that line (just went back and found it). Though I'm somewhat confused by "non-stateful instance data". From you email, I assume you mean exactly what I described. Is there a better label for that? I can't think of one that's not a couple sentances long, but I'm far from an OO guru.
Cheers, barneyb > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Dintenfass > Sent: Tuesday, March 16, 2004 10:26 AM > To: [EMAIL PROTECTED] > Subject: [CFCDev] Variables.instance/my - WAS: RFC, CFC Best Practices > > Barney: > > Are you saying you didn't get that from the document (at the > bottom)? Or, > are you reiterating as a show of support? ;) > > BTW, in answer to Jeffry's admonition to use > "variables.instance.foo" (or > "variables.my.foo") instead of simply "instance.foo" -- > personally, this is > the one exception I make in thorough scoping because in my > mind "instance" > operates as a "virtual" scope. Since it's so descriptive it > won't/shouldn't > be used as, for instance, a local variable in a method. > Thus, in my init() > I say: > > <cfset variables.instance = structNew()> > > But, from then on I can simply say "instance.foo" -- this > makes the code > more readable, IMO (I never did like using the word > "variables" to describe > instance data), and is protected from name collisions with > local variables > because I adopt it as a standard. > > > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of Barney Boisvert > > Sent: Tuesday, March 16, 2004 9:31 AM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] RFC, CFC Best Practices > > > > > > I've found that using a struct in the variables scope for > instance data (I > > use 'my') is helpful to separate actual instance data from > computed data. > > Take a User business object for example. It'll have > instance data such as > > 'name', 'username', 'password'. But it'll also very likely have a > > validate() method which will check the values of those > fields, and store > > error flags somewhere for later recall by getValidationErrors() > > or the like. > > > > Thus I'll have these fields: > > > > Variables.my.name > > Variables.my.username > > Variables.my.password > > Variables.validationErrors > > > > Making the distinction allows to memento machinery to work > > better, and also > > allows generic get/set methods to be "safe". > > > > > -----Original Message----- > > > From: [EMAIL PROTECTED] > > > [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Dintenfass > > > Sent: Monday, March 15, 2004 8: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]
