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
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of John Farrar
> Sent: Tuesday, August 05, 2003 5:59 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [CFCDev] Use of "instance" in 6.1
>
>
> Number one... yep, you are crazy.
>
> Number two... good thoughts, could you share how you use instance... give
> some examples and how the scope works with includes and so forth?
>
> Thanks,
>
> John Farrar
>
> ----- Original Message -----
> From: "Nathan Dintenfass" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, August 05, 2003 8:08 PM
> Subject: [CFCDev] Use of "instance" in 6.1
>
>
> > OK, now that RedSky is in the public we can talk about some of the
> > implications of the changes.
> >
> > I had assumed that once RedSky came out I would abandon using my virtual
> > "private" scope I always call "instance" and start using "variables".
> But,
> > now I'm not so sure.
> >
> > Why?
> >
> > For one, the variables scope in a CFC contains a key called "THIS" --
> which
> > still just feels very wrong to me.
> >
> > Also, the variables scope contains keys for every method in a component,
> > public and private.
> >
> > I find it attractive to think that the "instance" struct contains only
> > instance data and nothing else. I've used it in many places to
> do things
> > like persistence of a component instance (basically, by returning and
> > serializing "instance") and for things like cloning/mirroring
> of component
> > instances.
> >
> > Those may seem like esoteric cases, but they may be reason enough for me
> to
> > stick with "instance" (especially since they indicate to me there may be
> > future reasons I can't yet imagine to want all my instance data in a
> single,
> > unsullied, struct ("scope", if you will).
> >
> > But, I'm not sure -- and thus the purpose of this thread.
> >
> > Am I crazy to stick with "instance" over moving to "variables"?
> >
> > - 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).
