What is the problem with using CFC this. variables? Are they not thread safe? Where does MM document they are not thread safe? Is there example code that would cause a thread failure using this. variables?
Yes, the getter/setter proponents seem to think a function call is better CF and it is effective encapsulating. But for the code in me I cannot figure out why. It just seems to me that getter/setter for individual instance variables is a lot of extra runtime memory allocations, that in itself can cause memory leaks or thread failures. Functions in a CFC have namespaces just like this. scope variables. By CF definition, all function names are CF variable namespaces. The difference between public instance variables and private instance variables is when memory allocation occurs, loadtime or runtime. this. scope allocations happen at loadtime. Private variable allocation happen at runtime. The CFC this. variables are an extremely powerful feature in a CFC. If the application uses CFC this scope, CFC variable namespace act as a pass-by-name reference. The getter/setter functions most often use pass-by-value for individual instance variables. Whereas by using the CFC this. scope and simple expression statements, variable assignments conserve memory allocations because the CFC variable space is a CF data structure. (Note. Memory allocation is a runtime compiler function not memory use nor memory availability.) The good old equal sign in a statement is really a built-in function that is an elegant "setter". By adding user getter/setter functions individual instance variables complicates CFC data structure. The difference between an equal expression and a function call is when memory allocation occurs. Equal-expression memory space happens at loadtime and for the most part is fixed for that application execution. Getter/setter functions force dynamic memory allocation at runtime which causes changes in the application memory stack. It is these changes in memory stacks that expose risks for thread failures. Those of you who read this and who are encapsulation fans will not agree with me recommending the use of this. scope. So while I am on the topic, encapsulation means discrimination by design. It means declaring object definition and discarding all other possibilities. getter and setters is not encapsulation, it just one of many means to effect discrimination. Declaring a CFC defined with this scope instance variable is encapsulation by structure not by value. At 12:34 AM 12/25/2004, you wrote: >On Fri, 24 Dec 2004 21:26:18 -0600, Jared Rypka-Hauer - CMG, LLC ><[EMAIL PROTECTED]> wrote: > > Right... This is for moving from say... the DB to the screen via a > > single method call i.e. thisUser.get(12) > > <cfoutput>thisUser.fname</cfoutput> > >You're relying on the public "this" scope in order to be able to >directly access data members from outside the object. A lot of people >think this is a bad idea and you should use "variables" scope instead >and provide 'get' functions for the attributes: > ><cfoutput>#thisUser.getFName()#</cfoutput> > >This prevents accidental modification of data within the object. > > > where inside the CFC this.fName = query.fname and this.fName = > > query.lName and init(12) is passing the table's pkey value (possibly a > >So you'd either say: > variables.fName = query.fName; > variables.lName = query.lName; >or: > setFName(query.fName); > setLName(query.lName); >if you used public or private set methods instead. > > > I've got that THIS thing down fine. I guess it's the difference > > between private instance data and function-private variables that has > > me a little puzzled. > ><cffunction name="foo"> > <cfset var x = "exists only for this call of foo"/> > <cfset y = "exists across all calls for the same instance"/> > <cfset variables.z = "same scope as y"/> ></cffunction> > >None of x, y or z can be accessed from outside the object. x is >created fresh for every call of foo() (and is therefore thread safe). >y and z are created on the first call but the same y and z are updated >on subsequent calls (for the same instance). > >If the instance is in application scope, x is still local but y and z >are effectively application scope variables. > > > And even at that, I can see why one would choose to use function > > private variables for somethings, > >"function local" - private means something else. >-- >Sean A Corfield -- http://www.corfield.org/ >Team Fusebox -- http://www.fusebox.org/ >Breeze Me! -- http://www.corfield.org/breezeme >Got Gmail? -- I have 6 invites to give away! > >"If you're not annoying somebody, you're not really alive." >-- Margaret Atwood > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Gold Sponsor - CFHosting.net http://www.cfhosting.net Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188785 Archives: http://www.houseoffusion.com/cf_lists/threads.cfm/4 Subscription: http://www.houseoffusion.com/lists.cfm/link=s:4 Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
