Your concerns are valid... could you tell my why it is more of an issue with a object attribute for the consumer of the object than an object function? What is the difference between an attribute called cart.itemCount and cart.getItemCount()? If you changed the function it would mess up the client just like if you changed the variable. So by your logic would you also not expose the value through the function either? To achieve your thoughts purely and "protect" the outside world... object would be input only. Ah... but what if someone changed how the incoming interfaced worked. Do you see the paradigm? Your objection is in conflict with functions as much as attributes. (Note: I have voted on a wish list to have setters and getters in CFCs, as has Sean on that issue. We will see when that comes when it comes... until now, the internal and exposed external reflection are in the words of many, a good tradeoff.
Now... the reality is you understand how to keep from breaking a CFC that uses this technique. Don't change the purpose or existence of attributes. It would be the same with the functions/methods. They must continue to return the same variable type. Lastly, the private parts are never exposed. (variables.attributes is duplicated to this... not variables... so it is intentional exposure, and controlled) The private hidden variables are never exposed. There just is not issue here. The only attributes that are set are the ones you would expose through methods. Not all the internals, but essential and functional attributes. You would bloat your code and increase the "moving parts" of your application to do this same function. My method in a real way makes the object more reliable at times. (One of those trade offs.) John Farrar -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick McElhaney Sent: Tuesday, November 16, 2004 11:17 AM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] concerning this / variables scope in cfc On Tue, 16 Nov 2004 09:50:03 -0500, John D Farrar <[EMAIL PROTECTED]> wrote: > Also, who cares if they know the settings names inside the object, they > are protected! The CFC may be protected against outside code messing with its state. But the clients of that CFC are not protected against changes made to its implementation. Most of the time I'm not worried about code using my CFC incorrectly* (provided that the "correct" contract is clearly specified). If it does it won't break any of the other code. What I am worried about is being able to change the CFC without breaking code that uses it. (I don't want to track down all of those references, fix them, test, and redeploy. That's usually a lot of work. It's often impossible.) So I seperate the CFC into two parts. The public parts, known as the interface, contract, specification, or "what," will never change. The private parts, known as the implementation or "how," may change as the code evolves, as requirements change, to improve performance or readability, or some other reason. Often one CFC will be substituted with another CFC that has the same interface but a different implementation. The client code is blissfully unaware of the fact that it's working with two or more different CFCs. Patrick * As a courtesy to the programmers using the CFC (myself always included) I may try to make it difficult if not impossible to use the CFC incorrectly. -- Patrick McElhaney 704.560.9117 http://pmcelhaney.blogspot.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at [EMAIL PROTECTED] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com). An archive of the CFCDev list is available at [EMAIL PROTECTED]
