Because cf-talk doesn't allow "long posts", I'm going to post this in two sections.
Part I of II (or III). On Sat, 25 Dec 2004 19:43:57 -0800, Sean Corfield <[EMAIL PROTECTED]> wrote: > On Sat, 25 Dec 2004 19:39:06 -0700, Joseph Flanigan > <[EMAIL PROTECTED]> wrote: > > 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? > > If you store a CFC instance in a shared scope, "this" scope (and > "variables" scope) variables are also effectively in that shared > scope. If multiple requests call methods on that (shared) CFC and > those methods update variables in "this" scope (or "variables" scope) > then you will have race conditions and, unless you have written the > appropriate locking, your code will not be thread safe. > > This is basic stuff about shared scopes - CFCs just obscure it a little > because > > <cfset this.x = this.x + 1> > > doesn't look like it could be thread-unsafe. But if I wrote: > > <cfset application.x = application.x + 1> > > you certainly ought to recognize that as not being thread safe! > > > 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. > > I'm getting a bit tired of trying to explain why :( > > Go read about software engineering, there's mountains of stuff out > there that makes it crystal clear why encapsulation is a Good > Thing(tm). It's up to you whether you want to improve your skills or > not. > > > 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. > > Er, rubbish. Sorry, but that sort of comment just shows that you don't > understand... well, I don't even know where to start. Sorry, but that > sort of comment is just silly. *sigh* This is so frustrating... > > > Functions in a CFC have namespaces just like this. scope variables. > > Pardon? > > > By CF > > definition, all function names are CF variable namespaces. > > What? > > Neither of those statements make any sense to me. Could you explain > what you mean? > > > 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. > > No, you're wrong, absolutely wrong. > > "this" scope and "variables" scope are created at the same time - when > a CFC instance is created (at runtime). > > "function local" (var) scope is created when a function is called (at > runtime). > > > The CFC this. variables are an extremely powerful feature in a CFC. > > If you went round telling C#, Java and C++ developers to use public > data members like that, they'd laugh in your face. > > > If the > > application uses CFC this scope, CFC variable namespace act as a > > pass-by-name reference. > > "this" scope has absolutely nothing to do with pass-by-ref or > pass-by-value. Nor has "variables" scope. > > > The getter/setter functions most often use > > pass-by-value for individual instance variables. > > Technically that's correct but not in the way you think. If you pass a > simple data type, CF always copies it. If you assign a simple data > type, CF always copies it. If you pass a struct or a CFC, CF passes it > by reference, always, same with assignment of a struct. If you pass an > array, CF always performs a shallow copy of the array, same with > assignment of an array. The argument passing rules and the assignment > rules are identical. To be continued... ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| 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:188792 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
