This is an interesting idea.  The only drawback I see now is that you
can't "enforce" a specific argument type or return type.

Thanks!
MAD

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
Behalf Of Matthew Walker
Sent: Wednesday, January 07, 2004 7:13 PM
To: [EMAIL PROTECTED]
Subject: RE: [CFCDev] Best Practices Question: Getters and Setters

> Personally, I would keep the setters/getters separate as much as 
> possible.  I initially thought you could have a generice setter and 
> getter and specify the variable name to be set or retrieved.
> 
> Then, after a bit more thinking, "what if I want to add a specific 
> validation routine to only one variable".

I had code like this at one stage, but it would check to see if there
was a method called set[something]() or get[Something]() before applying
its own generic setter/getter code. This way there was a very tidy
override for the special cases. I don't currently use code like this as
I'm not convinced it's a good idea. Anyway, here's the getter I'd use (I
used to also maintain a structure of all the variables that were allowed
to be accessed, hence the "gettable" references):

        <cffunction name="get" access="public">
                <cfargument name="property" type="variableName"
required="yes">
                <cfset var getterName = "get" & arguments.property>
                                
                <cfif structkeyexists(this, getterName) and
iscustomfunction(this[getterName])>
                        <cfreturn evaluate("#getterName#()")>
                <cfelse>
                        <cfif not structkeyexists(gettable,
arguments.property)>
                                <cfthrow message="Cannot set
#arguments.property#. Use makeGettable(""#arguments.property#"") to
allow dynamic setting.">
                        </cfif>
                        <cfreturn object[arguments.property]>
                </cfif>
                
        </cffunction>


----------------------------------------------------------
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
www.mail-archive.com/[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 www.mail-archive.com/[EMAIL PROTECTED]

Reply via email to