The following information is also contained in my OO Lexicon, but I felt like it was sufficiently encapsulated (that's an OO term
) to go ahead and re-post it here.THIS, VARIABLES, and VAR Scopes
These are three of the variable scopes that are found within the world of a ColdFusion object or component, and three scopes that can make you pull the rest of your hair out when you don’t know how to think about them. In a nutshell, you’re looking at three increasing levels of variable privacy, from most liberal to most private.
The “THIS” scope holds items that can be directly accessed from anywhere inside OR outside of the object itself. Consider the following example of an instantiation of the myTest.cfc that has a variable called THIS.GLOBALVAL within it’s INIT method:
The component code...
<cfset this.GLOBALVAL = "Whatchoo lookin at Willis?" >
<cffunction name="init" output="false" returntype="myTest">
<cfreturn THIS>
</cffunction>
...
</cfcomponent>
The call from the outside template...
<cfscript>
myTestObj = CreateObject(“component”,”myTest”).Init();
myTestObj.GlobalVal = “I set you from outside of the object!”;
</cfscript>
In this example, because the variable GlobalVal was put into the THIS scope within our object, our application could directly access it as a property. Cool, if that’s what you intended to happen. Not cool if it wasn’t.
The VARIABLES scope within a component object is a scope that can be accessed by any method within the object at any time, in real time. In other words, if our component had set up a variable called Variables.LimitedVal, all methods will be sharing that one instance of the variable. If method one sets it to “5”, and later the app calls method two which reads that variable, it will see the value “5”. Any attempt, however, from outside the object itself to manipulate that value will result in an error. The following would FAIL:
The component code...
<cfset variables.GLOBALVAL = "Whatchoo lookin at Willis?" >
<cffunction name="init" output="false" returntype="myTest">
<cfreturn THIS>
</cffunction>
...
</cfcomponent>
The call from the outside template...
<cfscript>
myTestObj = CreateObject(“component”,”myTest”).Init();
myTestObj.GLOBALVAL = “I set you from outside of the object!”;
</cfscript>
And finally, the VAR scope. This scope is one which can be seen only from inside of the actual method itself. For example, I can have three methods, each that use a variable with the same name that was initialized within the VAR scope, and no method will ever see the variable used by the other methods. It is a VITAL thing that you initialize your private variables in the VAR scope inside of your methods, because by default they are set up in the VARIABLES scope, and who knows WHAT havoc will occur if you have methods sharing variables that were intended to be private. Consider the following sample of initializing a variable in the VAR scope:
<cffunction access="public" name="sampleMethod" output="false" returntype="void">
<cfargument name="headlines" type="array" required="yes" >
<cfargument name="sourceID" type="numeric" required="yes">
<cfset var iterations = 0>
<cfset var urlitems = "">
<cfset var newInsertItems = arraynew(1)>
</cffunction>
Only the ‘sampleMethod’ method will be able to see and manipulate those variables set using the ‘var’ scope. VAR is so private, that every other method within our component could initialize variables with the same name within their own var scope and no overlap would occur.
You are not logged in, so your subscription status for this entry is unknown. You can login or register here.
- What havoc = if you forget to VAR your CFSETs AND store your queries (yes these are objects with scope also!) these will stay in server memory for that thread until they are dumped or the server goes down. For queries, I've used storage structs and then attach a query as part of that struct (so it gets destroyed at end of the function execution): and
The havoc comes when you have fifty different users in all parts of the world hitting the same CFC at the same time, and in a nutshell, "their data gets crossed". You could potentially have user A login first, user B logs in second, then user A starts seeing user B's data. I'd call that havoc. I'm sure the rest of the CFers out there could come up with a whole book full of ugly scenarios that could rightly be called havoc, too, just because someone did not scope their variables properly.