Attributes don't prevent the use of a calculated variable. If you want a calculated variable... set one. Use a method/function. Yet, if you have an attribute like "created"... it doesn't need to be calculated. This is where it would help to think outside your box Sean. It's time to cut some windows! ( HEH ) If you are internally storing something as a static variable... then it can likely be exposed as a static variable to the container application also, but as you may point out, not always. This is why I use variables.somesetting and variables.attributes.somesetting internally to differentiate between the two. Only the variables in the second scope get pushed to the object attributes. Also, who cares if they know the settings names inside the object, they are protected! There is NO RELEVANCE to if the user knows what name they have if in reality he cannot access them anyway. Furthermore, someone can create a more "detailed" exposure method if that is an issue, as I said earlier. There is not a necessity to couple the names... that could be changed at any point. So neither the consumer or developer is tied to the internal names matching the external attribute names.
Again, it amazes me that you are so conservative in programming concepts. They are guides, not absolutes ... and we need to know when they apply rather than finding out how to program when these philosophy rules apply all the time because the "council" proclaims it. John -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Corfield Sent: Tuesday, November 16, 2004 12:20 AM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] concerning this / variables scope in cfc On Mon, 15 Nov 2004 18:00:50 -0500, John D Farrar <[EMAIL PROTECTED]> wrote: > 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. Actually Pat is correct (and you are wrong). By exposing an attribute as a variable - even "readonly" using your scope reassignment hack - you are no longer able to change the implementation to get calculated-on-demand attribute values - getSomething() doesn't need a real attribute variable underneath it but your method does... which is why your method, although you find it useful, is not really a good idea. -- Sean A Corfield -- http://www.corfield.org/ Team Fusebox -- http://www.fusebox.org/ Breeze Me! -- http://www.corfield.org/breezeme Got Gmail? -- I have 1 invite "If you're not annoying somebody, you're not really alive." -- Margaret Atwood ---------------------------------------------------------- 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]
