This is OT, but for those of you who are curious:
It works in other .NET languages too. You actually don't need to know any
implementation details - a Property is really just a shortcut for writing
getters and setters. Sometimes, it is actually _more_ intuitive than using
a function, as a function connotes an action being performed on an object,
whereas a property is usually just associated with a data element or
attribute. Internally, the properties are really just getters and setters.
In VB.NET, for instance, they're defined like this:
Public Property Name As String
Get
Return _SomeVariable
End Get
Set(ByVal Value As String)
_SomeVariable = Value
End Set
End Property
You can write any code you like inside of those Get and Set methods -
they're functionally equivalent to an actual function call. This allows you
to do validation, etc, inside the getters and setters (such as
type-checking, pattern matching, persistence, etc). It is functionally no
different than writing:
Public Function getName() As String
Return _SomeVariable
End Function
Public Sub setName(Value As String)
_SomeVariable = Value
End Sub
The only differences are in how the object is accessed. Take an Employee
object for instance. An Employee could have many attributes, such as Name,
Position, Salary, etc.. There could also be actions you perform on this
Employee, such as Promote(), Fire(), etc.. Using properties (IMO, anyway),
makes more sense in OOP terms than getters and setters, since they more
accurately model the object itself. Take this pseudo code for example:
employee = New Employee()
employee.Name = "Roland"
employee.Position = "CTO"
employee.Salary = "Eleventy Billion Dollars"
employee.Promote()
It makes it very clear that Name, Position, and Salary are really just
attributes of the object, while Promote() is an actual action performed on
the object. Under the hood it's all the same, but it sure makes working
with objects a lot more graceful.
Anyway, sorry for the OT, but I thought some of you may be curious in how
another language handles this (quite nicely, IMO).
Roland
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Steven Boynes
Sent: Monday, November 15, 2004 10:11 PM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] concerning this / variables scope in cfc
thats pretty cool, I didn't know VB6 had that (I've never programmed in it).
Its probably a double-edged sword though...I mean you only have to enter
what 5 less characters "get...()" but at first take I thought it was a
violation of OO principles, actually isn't it though? because it makes the
assumption that you know the names of the internal storage variables when
you really shouldn't, that way the cfc could store stuff wherever it wants
and by using the accessor you don't have to know where it comes from.
>From: "John D Farrar" <[EMAIL PROTECTED]>
>Reply-To: [EMAIL PROTECTED]
>To: <[EMAIL PROTECTED]>
>Subject: RE: [CFCDev] concerning this / variables scope in cfc
>Date: Mon, 15 Nov 2004 21:44:23 -0500
>
>Right... different beast. There are different approaches... I use the
"this"
>scope as read only... less cryptic, and if they ever add getter/setter
>methods to CFCs... it will still be compatible with that protection
scope if
>and when they do. I do not use it to set values though.
>
>John Farrar
>
>
>-----Original Message-----
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf
>Of Dave Watts
>Sent: Monday, November 15, 2004 8:57 PM
>To: [EMAIL PROTECTED]
>Subject: RE: [CFCDev] concerning this / variables scope in cfc
>
> > 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?
>
>The problem is that, while these things may seem the same they're really
>not. Within VB, when you specify your property getters and setters, you
can
>control and limit access to properties as appropriate. The
"This" scope
>doesn't allow you to do this. If you could automatically map property
names
>to getter and setter methods, that might be nice but I suspect it would
be
>difficult to make that backward-compatible.
>
>Dave Watts, CTO, Fig Leaf Software
>http://www.figleaf.com/
>phone: 202-797-5496
>fax: 202-797-5444
>
>----------------------------------------------------------
>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]
----------------------------------------------------------
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]
