Andrew,
Your overall example works fine, except how do you know for sure that the Width will always be an Integer? In that, width = "monkey" or width = "1px"
This is another reason as to why you don't want to allow exposure to the
property publically as you can't validate the data being set/retrieved in many ways (that and you have no control over it on a per object basis).
In some languages you can use things like this:
public function get width():Numeric {
return _width;
}public function set width(intValue):Numeric {
_width = intValue;
}So you could still use oInput.width = "x" but inside the "set" method, you could validate the data coming in and if it contains "px" or something like that, you could strip that out etc so at the end of the day the metrics are always integer.
Since Coldfusion MX doesn't have this, you pretty much don't use the this scope, simply for the reason that bad things CAN & sometimes will happen.
I guess the main question with CFMX is simply the fact that the "this" scope always represents a public property, and accessing properties on a CFC object without any validation server-side, could lead to problems. It may work 99.9% of the time, but are you prepared to wait out that .1% chance of it not working?
As for the actual "this" scope in other OOP languages, personally I know i've used it in ActionScript 2.0 a lot (even though its a sugarcoated syntax language :D) for the simple reason of differentiating between a object property and a local property.
Scott.
Andrew Scott wrote:
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/
