Fun with Functions and CFCs I - Understanding CFC Private Vs Public - this is not Java!
posted under category: ColdFusion on December 10, 2007 by Nathan
I was reminded to blog something I've been thinking about and playing with for a while from the CFTalk List, so I'm starting a blogging series on the fun things you can do with dynamic languages, specifically with ColdFusion. This is part 1. We won't go over anything truly revolutionary in this series, but I do hope to invoke some good brain activity.
Before I get to the really fun stuff, I need to make sure we're on the same playing field, so this first entry is just instructional.
ColdFusion Components (CFCs) Intro
CFCs are ColdFusion's answer to object oriented programming. They allow some OO-type syntax borrowed from CF's big brother Java. They allow access modifiers of Private (can be called only from within the current CFC instance), Package (can be called from CFCs in the same directory), Public (can be called from any CF code on the server) and Remote (Provides the entry point for web services, flash remoting, Flex messaging and invoking a CFC directly from a URI).
Public Vs Private - the clever trick
When you instantiate a CFC (be it using createObject, <cfobject> or <cfinvoke>), ColdFusion, in the background, creates 2 structures (structure = struct, aka hashtable or map, aka name-value pair object, a collection of in-memory variables and data), one called Variables and one called this.
(jump break)
Variables is the private variables scope - methods and properties that appear here are not publicly available. Just like a .cfm page has a variables scope, shared with any cfincluded files, the variables scope is internal to the CFC, shared with any functions. The danger here is the old var your variables problem - if you don't specify a scope in a CFC, just like in a cfm, your variable will be set in this variables structure and can interfere with other seemingly independent functions that end up sharing the same Variables. All of your public, private, et. al. methods will appear here. Also, any variable you place in the variables scope is recognized as private.
This is the publicly available scope. Any methods you mark as public will appear here as well as in the variables scope. To set a variable here, you have to explicitly set it into This. Conveniently, the Variables struct actually contains the This struct. From within the CFC, This is located at variables.this. Externally, it is the only thing visible. One thing you will see in CF is <cfreturn this /> - this returns the public interface for an object, essentially returning the object itself from a method you called, for chaining methods. It's extremely popular with a CF standard practice, the init() method.
So this is the clever trick. Variables = private, Variables.This = public. I've never heard it done like that before, but it does work nicely.
Tomorrow, the real fun begins.