Sean, I can give you thousand of examples where to use the this scope, and you could give me thousands of where to not use it. But to plain say don't is not right for those wanting to know.
Here is a very simple example where I do use it. <cfset oInput.Caption = "Test" /> <cfset oInput.Width = 100 /> <cfset oInput.Display() /> <cfcomponent> <!--- Default values ---> <cfset this.Width = 100 /> <cfset this.Height = 100 /> <cfset this.TextColor = "#FFFFFF" /> <cfset this.BackColor = "#cccccc" /> <cffunction name="Display"> ..do Display code </cffunction> </cfcomponent> Now in this case here I have a pile of default values that might or might not change, so in this example why would I want to pass the values that do not change each and every call to the display function? Now I could use oInput.SetWidth(100) but again it's a choice not a must do way of doing things? Regards Andrew Scott Technical Consultant NuSphere Pty Ltd Level 2/33 Bank Street South Melbourne, Victoria, 3205 Phone: 03 9686 0485 - Fax: 03 9699 7976 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean Corfield Sent: Wednesday, 30 June 2004 10:20 AM To: CFAussie Mailing List Subject: [cfaussie] RE: this On Wed, 30 Jun 2004 07:09:42 +1000, Andrew Scott <[EMAIL PROTECTED]> wrote: > If its bad why do MM allow it to be used, why do macromedia allow for > these problems? In 6.0, you had no choice - there was no private scope. For other languages, public data has always been an option for developers but has also always been considered bad practice for the most part. > Anyway I guess what I am saying is that from a developers point of > view, if the concept is bad then why put it there in the first place? Go ask the designers of C++ and Java and C# which all have public data members. They'll probably answer with something about efficiency / performance. But they'll also say that encapsulation is more important (maintainability is more important than low-level performance in most situations). > But to just turn around and say its bad and don't use it, means > nothing to most who don't understand why it is there in the first > place. Maybe a bit more documentation and clearly explain why you > shouldn't use it and when it is safe to use it would be better. There is a wealth of OO documentation out there that explains why public data members are in general a bad idea. As Mark and I have said, you can't really learn OO from CF alone - you need to go out and study Java at least. And the information about practices like public / private data members are there in all of the Java material... --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
