Joe, The actual code for the getter is variables.instance[arguments.name] so there's no possibility of someone blowing away a method.
Hal -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joe Rinehart Sent: Friday, January 20, 2006 8:29 AM To: [email protected] Subject: Re: [CFCDev] Bean and CFC question > > why am I writing separate getters and setters when I no longer am > > concerned about pseudo-static typing? So, I wrote universal > > get(propertyName) and set(propertyName, value) methods for BaseComponent.cfc. > > My initial reaction was "yuck!" until I saw your caveat about > detecting and calling getX() if it is defined. That's pretty sweet. Ugh, I'm still against it. It allows (at least a portion of) your CFC's private scope to be manipulated directly, essentially tossing out the whole of data hiding. For instance, say I had the following CFC: <cfcomponent> <cffunction name="set"> <cfargument name="name" /> <cfargument name="value" /> <cfset variables[arguments.name] = arguments.value /> </cffunction> <cffunction name="get"> <cfargument name="name" /> <cfreturn variables[arguments.name] /> </cffunction> <cffunction name="blowUpEarth" access="private"> <cfoutput>Earth go boom!</cfoutput> </cffunction> <cffunction name="createInterstellarBypass"> <cfset blowUpEarth() /> <cfreturn "Obstacles cleared." /> </cffunction> </cfcomponent> And then I run this code: <cfset tmp = createObject("component", "temp") /> <cfdump var="#tmp.createInterstellarBypass()#" /> <cfset tmp.set("blowUpEarth", "BOOM!") /> <cfdump var="#tmp.createInterstellarBypass()#" /> My first call to createInterstallerBypass() will work, but the second will fail. The only thing to blame is that the API's consumer didn't know that there was a private method named "blowUpEarth" - but wait, how can we blame an API user for not knowing the details of the implementation? Sure, we can "protect" things by limiting the generic set() to only alter something like a variables._unsafe structure, but either way we slice it, the consumer is setting unchecked values into a private scope, and we're adding unneeded implementation complexity for no reason I can see other than not wanting to take the five minutes to write get/set methods. Being able to dynamically type things is pretty powerful, but I'm afraid we're going to start taking it to extemes where it becomes impractical. Like all things, I think there's a balance point: I've used type="any" for a long time for many things, but I've also used type="be.what.i.need.you.to.be" in places where it's called for. -- Get Glued! The Model-Glue ColdFusion Framework http://www.model-glue.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] 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/[email protected]
