In certain languages, like VB6, you have property methods (Get & Let). When you use: obj.firstName = "Mike", the Let method is implicitely called.
To me, the "this" scope is the same thing, but in a different language. I got away from using the "this" scope in favor of setters and getters, but I probably only did that because of other people's suggestions. Would it make a difference if CF supported property methods such as VB6? Would that make it "better" in other's minds? Would it then be appropriate to use "this.firstName"? Would anyone else want CF to support property methods? M!ke -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John D Farrar Sent: Monday, November 15, 2004 5:01 PM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] concerning this / variables scope in cfc What would that be called "excapulation" vs "encapsulation". Actually you could still write the internals to deal with that... it would just require a little more features. But essentially you are wrong Pat. It is no more dependent to address a variable than a function. You would just have to make your use of the variables.attributes inside the CFC an abstract connection. I don't think you get the point, just like "getAttribute1()" gives you attribute one, so does myobject.attribute1. It's a question of style... and there is a trend of carrying this concept to an extreme. This principle of abstraction is a virtue, not an absolute. Any virtue that neglects it's relationship to other virtues becomes a handicap. I have heard "several" of the gurus refer to these things as tradeoffs. They are not tradeoffs... they are "implementations" of programming virtues. Now I am not asking you to adhere to my methods, but they are useful! All you have to do is change the mechanism inside the CFC that sets the object attributes, and the "internals" are free. Again, if you can't have object attributes because it controls the internals, you couldn't have object methods to return them either. If you are worried about the internals... just change the mechanism that sets the external attributes. :) Find a solution... not just a problem. It will make you a better developer! (And forgive sensitivity on this one... just been shot up a bit on this list over religious devotion to some high priests guides to unproven principles. The principles are indeed virtues... but knowing when they don't apply is a missing discussion. It's like everyone is "afraid" to say... this is a bad time to prefer encapsulation, so they don't look at anything that might not adhere to that holy grail virtue.) John -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Patrick McElhaney Sent: Monday, November 15, 2004 12:33 PM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] concerning this / variables scope in cfc On Mon, 15 Nov 2004 11:19:55 -0500, John D Farrar <[EMAIL PROTECTED]> wrote: > I do something with "this" scope still. I create a > variables.attributes scope and a private function to set this = > duplicate(variables.attributes) function. Then I use the variables as > read only... even if a user messes with them, they will return the > wrong values, but they won't keep the CFC from having correct internals. It doesn't matter. You've still hung depencencies on those internals. You can't change the internals of the CFC without breaking code that depends on it. Patrick -- Patrick McElhaney 704.560.9117 http://pmcelhaney.blogspot.com I still have 5 gmail invites. ---------------------------------------------------------- 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]
