> > 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]
