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.
Heh, I was waiting for this email :)
For one, the variables scope in a CFC contains a key called "THIS" -- which
still just feels very wrong to me.
I'll write up an explanation of why this is so (and why it actually does make sense when you understand the background). I'll need to chat with the CF team about how much of the internals around "variables" scope they are willing to share...
Also, the variables scope contains keys for every method in a component,
public and private.
Which, again, actually makes sense when you understand how the scopes work and how name lookup behaves.
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.
Yes, this is still reasonable, especially since you may have additional non-public data that represents 'housekeeping' information within a CFC that is not related to the data you're talking about.
Even with the 'instance' workaround for the former failings of "variables" scope, I tended to have 'instance.data' as a struct holding the CFC's instance data that needed to be treated as a single 'packet' (for serialization or other 'group' operations) and then 'instance.xxx' represented other data held by the CFC instance.
An example is where a CFC has some serializable data (in 'instance.data') and also some cached information that is purely an optimization (in 'instance.cache' perhaps) that is nothing to do with what needs to be serializable.
What it really comes down to is what your CFC needs to do with its instance data...
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive." -- Margaret Atwood
----------------------------------------------------------
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).
