I've been working on similar code taking the idea, originally, from Isaac Dealy's onTap framework.
This is how I've seen things: 1) (Like in the onTap Framework) the universal getter/setter first checks to see if a dedicated getter/setter exists (these must be named "getPropertyname"/"setPropertyname" for this to work). If one does work, it uses them. 2) They then checks to see if a special struct, "PropertyDefinition" exists and if the property name is a key in that struct. That struct contains the same information you'd see in CFPARAM (type, default value, etc) and CFPARAM is used to test type (for both output and input). This works because for a getter/setter pair the input and output types will always be the same. 3) If all of that fails it sets/gets the property "blind". I would have originally liked to use the CFPROPERTY metadata to handle the type checking, but as you can imaging that was both slow and ugly; thus the PropertyDefinition struct. My one stumbling block currently is testing for component type (or even for component existence); something I'd truly like to do. Any ideas how to best go about this? Jim Davis > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > Of Dawson, Michael > Sent: Thursday, January 08, 2004 8:57 AM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] Best Practices Question: Getters and Setters > > 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] ---------------------------------------------------------- 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]
