On Tuesday, May 27, 2003, at 17:30 US/Pacific, Shawn Grover wrote:
> We were initially going to create get and set methods for member
> variables (not in the THIS scope), but quickly realized this was
> meaningless, because I was free to set variables on the object
> willy-nilly.
But the variables you set on the object are in "this" scope which you
can ignore inside the CFC and only use the unnamed scope.
> <cfscript>
> oPos = createObject("component", "myposition");
> oPos.x = 5;
> oPos.y = 6;
> oPos.z = 15; //This is not an officially supported property
> oPos.MyOwnProperty = "Hi ya Bob"; //another "unofficial" property
> </cfscript>
>
> If you do a cfdump of the oPos object, it DOES reflect the two
> additional
> properties, even though they were not defined in the CFC.
Correct. But cfdump does not show any non-public data that the CFC has
set itself, which is the key point.
> So, doing get's
> and set's to enforce data type becomes meaningless - instead of saying
> oObj.getProperty(); a user could do oObj.Property = 1;, and x =
> oObj.Property;, bypassing the functions.
Consider this:
foo.cfc:
<cfcomponent>
<cffunction name="getFoo" returntype="string">
<cfreturn foo/>
<cffunction>
<cffunction name="setFoo">
<cfargument name="newFoo" type="string"/>
<cfset foo = arguments.newFoo/>
</cffunction>
<cfcomponent>
rogue.cfc:
<cfset foo = createObject("component","foo")/>
<cfset foo.setFoo("hello")/>
<cfoutput>#foo.getFoo()#</cfoutput>
<cfset foo.foo = "goodbye"/>
<cfoutput>#foo.getFoo()#</cfoutput>
You will see that using the unnamed scope instead of "this" scope
protects your data - the foo.foo = "goodbye" has no effect on 'foo'
inside the CFC (because it sets 'this.foo' instead).
A common idiom folks seem to have adopted is actually this:
foo.cfc:
<cfcomponent>
<cfset instance = structNew()/>
<cffunction name="getFoo" returntype="string">
<cfreturn instance.foo/>
<cffunction>
<cffunction name="setFoo">
<cfargument name="foo" type="string"/>
<cfset instance.foo = arguments.foo/>
</cffunction>
<cfcomponent>
This creates a non-public (and therefore protected) instance variable
(called 'instance') which acts like a scope for all your instance data
- and also allows your setXxx() method to use the same name for its
argument as for the instance variable itself (which is not possible
using the unnamed scope).
In theory, you ought to be able to use "variables" scope instead of the
"instance" 'scope' shown above but, right now, there's a bug in CFMX
which makes "variables" scope break in CFCs (which will get fixed in
due course).
Hope that helps explain how to use get/set to encapsulate your data and
avoid 'malicious' code outside the object from messing with it.
Sean A Corfield -- http://www.corfield.org/blog/
"If you're not annoying somebody, you're not really alive."
-- Margaret Atwood
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4
Subscription:
http://www.houseoffusion.com/cf_lists/index.cfm?method=subscribe&forumid=4
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Get the mailserver that powers this list at
http://www.coolfusion.com
Unsubscribe:
http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
