But part of all this confusion is because CFPROPERTY is a lame duck -
next to useless. Maybe if CFPROPERTY acted like VB's properties, it'd
make more sence
here's how VB.NET would handle the same scenario as Scotts example
Public class HelloEverybody
Private _width As Int32
Public Property width() As Int32
Get
Return _width
End Get
Set(ByVal value As Int32)
_width = Value
End Set
End Property
end class
with the call being
theWidth = myObject.width (to get)
myObject.width = 50 (to set)
It's not a lot different to using public methods to set (protected)
values but it's much neater IMHO, and certainly clarifies what you're
playing with.
In CF protected properties can be emulated (variables scope) but there
is still no uninheritable private properties.
just 2c worth
barry.b
-----Original Message-----
From: Scott Barnes [mailto:[EMAIL PROTECTED]
Sent: Wednesday, 30 June 2004 2:02 PM
To: CFAussie Mailing List
Subject: [cfaussie] Re: this
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/
---
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/
