Are the instance variables visible if a function "<cfinclude>"s a file... to the logic inside the included file? (I am working on a fusebox like "action" cfc that has a do function. Of course in the light of the methodology the include function for the switch and settings is done from the do function inside the cfc.) So, this is an interesting consideration in light of some of the technology we are putting together. (The coolest part... is that the "do" function can be called at any time! ... well, during the circuit action execution that is. We are rewritting part of the code so the appliation and api can be shared with a non-fusebox application. I love code reuse and portability!)
John Farrar ----- Original Message ----- From: "Nathan Dintenfass" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, August 05, 2003 9:28 PM Subject: RE: [CFCDev] Use of "instance" in 6.1 > Since you asked...... ;) > > I use "instance" to hold all data that is specific to an instance of the > CFC. Often I see it called "private" data, but given the sensitivity of the > java folk in the CF community I avoid that term when possible. > > So, let's say I have a really simple component called person.cfc and it > looks something like this: > > ------------- person.cfc --------------------------- > <cfcomponent> > > <cfset instance = structNew()> > > <cffunction name="init"> > <cfargument name="firstName"> > <cfargument name="lastName"> > <cfscript> > setFirstName(arguments.firstName); > setLastName(arguments.lastName); > </cfscript> > </cffunction> > > <cffunction name="setFirstName"> > <cfargument name="firstName"> > <cfset instance.firstName = arguments.firstName> > </cfffunction> > > <cffunction name="getFirstName"> > <cfreturn instance.firstName> > </cffunction> > > <cffunction name="setLastName"> > <cfargument name="lastName"> > <cfset instance.lastName = arguments.lastName> > </cfffunction> > > <cffunction name="getLastName"> > <cfreturn instance.lastName> > </cffunction> > > </cfcomponent> > > ----------------------------------------------------- > > Now, obviously that's pretty boring, but you get the idea that "instance" is > used to hold all of the instance data for a given person. One nice thing > about using instance, in my mind, is that I don't worry about name conflicts > between arguments/local variables and my instance data (see the setters > above) -- some people say it's a bad idea to do your naming like that > anyway, but that's another story. Incidentally, that's a secondary (and > minor) reason "variables" is less attractive to me -- possibility of name > conflicts. > > Now, with the above component, I could easily create a method called > toSerializable(), which basically just returns "instance" (for some > components I've built there's more to do, but often that's enough) as well > as a populateFromSerializable() which takes a struct and populates > "instance". Using methods like that it's really easy to build basic > persistence mechanisms for components (something I've done successfully a > couple of times). It's also fairly easy to create clone() and mirror() > methods because you have all the instance data in a neat little package. > Both of those scenarios will be more of a hassle if using straight > "variables.foo" syntax, and given that creating a struct in the > "pseudo-constructor area" has miniscule overhead I don't there are > performance reasons to not keep going the way I've been going. > > I think one of the biggest issues will be how other CF developers read my > code, however, if using "variables.foo" becomes the endorsed way of doing > things (which it seems likely to do). I also teach a CFC class, so I'm > trying to decide if I should remove the use of "instance" from all my > examples, lest folks get confused. > > To answer your other question: With includes instance works same as any > unscoped variable (and with RedSky that's a non-issue anyway) because > "instance" is really just an unscoped variable that happens to get used in a > way that makes it look like a scope (the real scopes in CF act just like > structs anyway, right?). > > So, that's probably way more detail than you wanted, but maybe it will give > more context for others to chime in with opinions. > > - Nathan > > > > > > ---------------------------------------------------------- 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).
