Jared Rypka-Hauer - CMG, LLC wrote:
Dave's right...
The Variables scope IS the private scope.
Jared and David are correct. Although, IIRC....MX6.0 had issues with
CFCs and the private scope. That should be a moot point now since
everyone probably has applied the updater to 6.1.
It's the THIS scope that's public, can be directly gotten and set
against, and breaks any and all rules of encapsulation.
variables.foo = "private"
this.bar = "public"
In my experience (in regards to MX6.1 & 7), I rarely use the THIS
scope. So far I have only seen the need to "break" encapsulation by
using the THIS scope in "lightweight transfer objects" [LTOs] (which is
probably better described as a transfer struct). In most situations of
mine, I rarely see the need to using a full-blown TO with getters as it
appears to just be a "lighter-weight" bean (BO). In most of my
circumstances, it just seems silly to create a TO that is "nearly" the
same as the bean (a bean minus the setters). That is why I use a LTO
with just public variables in "most cases". Basically, it's just a
fancy struct within a CFC. See the Mach-II Info sample app for an example.
So your getters and setters can be the window on the CFC's private
data, provided that they're public methods. Sometimes you're going to
have a really restricted API and you may only have one public getter
out of 20 methods. But yeah, your getters and setters are for
manipulating variable-scope data.
Again, this happens a lot with me - restricting setters are something I
do a lot (i.e. private instead of public setters). Sometimes I only
want CFCs to be able to set data on init(), because there is no need to
mess with the data outside of the CFC during the lifetime of the object.
Laterz,
J
.peter
--
Peter J. Farrell :: Maestro Publishing
blog :: http://blog.maestropublishing.com
email :: [EMAIL PROTECTED]
phone :: 651-204-0513
Fatal Windows Error 039: Cray not found - System Halted.
--
----------------------------------------------------------
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]
