Part II of II (I hope) > > > 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. > > If you're arguing that obj.x = 42; is a bit more efficient than > obj.setX(42); then I'll agree but you seem to be saying it in a very > strange way. And that level of efficiency certainly does not outweigh > basic software engineering principles like encapsulation. > > > (Note. Memory allocation is a runtime compiler function not memory use nor > > memory availability.) > > "runtime compiler" is an oxymoron - something is either compile-time > or run-time. > > > The good old equal sign in a statement is really a built-in function that > > is an elegant "setter". > > ...that has no data validation and provides no way to ensure the > integrity of the CFC instance. It'll let you stick any old values into > an object. > > joseph.age = -42; > > That ought to tell you it's a bad idea. > > joseph.setAge(-41); > > That can at least check that the age value is sensible. > > That's why we use setters. It also lets us change the representation > of the data within the object without having to change all the client > code that uses the object. > > A Person CFC could store the year of birth and calculate age on demand > or it could store both or it could store age and calculate the year of > birth on demand. With getters and setters, the CFC can choose any > approach and client code isn't affected. With your approach, once a > choice is made, it can't change. That's brittle and creates a program > that is hard to maintain. > > > By adding user getter/setter functions individual > > instance variables complicates CFC data structure. > > Yes, for the trade off of a more robust design. > > > The difference between > > an equal expression and a function call is when memory allocation occurs. > > Er, nope. > > > Equal-expression memory space happens at loadtime and for the most part is > > fixed for that application execution. > > Nope, not true. a = b could cause all sorts of memory allocations and > deallocations at runtime. > > > Getter/setter functions force dynamic > > memory allocation at runtime which causes changes in the application memory > > stack. > > Calling a function causes the stack to grow of course, as a new stack > frame is created and when the function returns, the stack shrinks > again. That's the nature of a function call. However, if you look > under the hood, you'll see that CF compiles a = b down to a function > call anyway - because CF is a dynamic, loosely-typed language that has > to perform quite a bit of work to assign things sometimes... > > > It is these changes in memory stacks that expose risks for thread > > failures. > > Are you saying that a basic function call can cause a thread failure? > I guess we shouldn't use functions? What about custom tags? They cause > the stack to grow and shrink too you know, as does <cfmodule>. Sheesh, > we'd better write all our code as one monolithic .cfm page with no > modularization, no functions, no custom tags... > > > Those of you who read this and who are encapsulation fans will not agree > > with me recommending the use of this. scope. > > There's some far more fundamental problems with what you're saying > than just recommending "this" scope, I'm afraid. > > > Declaring a CFC defined with this scope instance variable > > is encapsulation by structure not by value. > > No, using "this" scope is a complete lack of encapsulation. Perhaps > you need to go read up on what encapsulation means? > > I'm sorry if this response is harsh but your post is full of so many > apparent misunderstandings about how things work that it's hard to > know where to start. Spreading these sorts of misunderstandings > damages ColdFusion's image - people in the Java and .NET world won't > take CF seriously when they see stuff like this on our mailing lists. > --
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Special thanks to the CF Community Suite Silver Sponsor - CFDynamics http://www.cfdynamics.com Message: http://www.houseoffusion.com/lists.cfm/link=i:4:188793 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=11502.10531.4 Donations & Support: http://www.houseoffusion.com/tiny.cfm/54
