Re: [CFCDev] cfc check

[Peter J. Farrell]

Dawson, Michael wrote:  Only the untalented can afford to be humble. --  > Something that I've seen someone do was use a bit of trickery and allow the same function that gets the variable to set it, I thought it was quite neat.     > Something like  > <cffunction name="setServer" access="private" returntype="string">  >       <cfargument name="newValue" required="false" type="string">         >     <cfset var returnValue = "" />  >      <cfif StructKeyExists(ARGUMENTS,newValue)>   >          <cfset variables.instance.server=arguments.newValue>  >    <cfelse>  >         <cfset returnValue = variables.instance.server>   >    </cfif>  >     <cfreturn returnValue />  >  </cffunction>    > then call it either by not passing an attribute to get the value and passing an attribute to set it.    This seems a bit hokey to me.  setServer, used as a getter, could confuse me and maybe other people. I'm not slamming or flaming this...just my thoughts.  Although it appears fast - I think I'd get a headache trying to call a setter for a getter (as well a the confusion teaching my API to someone else).  Also, it's constantly having to evaluate if you passed a new value instead of doing what it should be doing - either setting or getting.  Depending in what situation you're using your getters/setters, it actually *might* slow down your program a bit (I have no information to prove this...just food for thought...so just take a grain of salt). For some reason, I don't like the fact that if I actually setting something - it's also returning "" [essentially null] back.  All of my setters are set to returntype="void".  I guess in the end you are losing some of your control how someone accesses your CFC - such returntype and an extra evaluation to see if the argument was passed or not.  Secondly, since you have to set the required attribute to false - your losing some data type checking here - maybe you meant to use it as a setter but forgot to pass an argument. <!--- EXAMPLE using hybrid ---> <!--- I really want to set a new piece of data, but during my initial programme I forgot to pass an argument ---> <cfset setRecord_locator() /> <cfset variables.local_copy = setRecord_locator() /> <!--- I never changed the original data member which may this hard to debug because it's hard to see ---> <!--- EXAMPLE with getter/setter ---> <!--- I really want to set a new piece of data, so use the setter ---> <cfset setRecord_locator(12345) /> <cfset variables.local_copy = getRecord_locator() /> <!---  I got the new info and it's easier to read what's really happening without knowing the internals of the CFC ---> As an illustration - I'll post a common getter/setter and it's actually has less lines of code (6 instead of 10 not including the line break) to it than a "hybrid" getter/setter: <cffunction name="getRecord_locator" access="public" output="false" returntype="numeric">     <cfreturn variables.instance.record_locator />  </cffunction> <cffunction name="setRecord_locator" access="public" output="false" returntype="void">     <cfargument name="record_locator" type="numeric" required="true" />     <cfset variables.instance.record_locator = arguments.record_locator /> </cffunction> Maybe I just like the separation of getters/setters or follow the java pattern to the "T" or the old "encapsulate what varies".  Also, this solution could make a hole in your API.  I sometimes have instance data that is set in the init() with private setters and public getters.  I don't want anybody to change that instance data.  Therefore I shouldn't make the setter public - however if it's hybridized and I want a public getter - the setter has to be as well.  In the end, this probably all a moot point.  I like doing this "right" the first time - and I'd rather not have to refactor such low level code. Best, .peter -- Peter J. Farrell :: Maestro Publishing blog :: http://blog.maestropublishing.com email :: [EMAIL PROTECTED] phone :: 651-204-0513 ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/cfcdev@cfczone.org