ColdFusion 10 Beta - Closures And Components And The THIS Scope

The last couple of days have been really exciting as we've been exploring the new Closures and Function Expressions that have been added to ColdFusion 10. First, we looked at the general structure and behavior of closures and function expressions; then, we looked at how closures interact with threads; now, I'd like to take a quick look at how closures interact with ColdFusion components (CFC).

THIS Is Never That Simple - Runtime Execution Context Bindings

When you invoke a function, it gets invoked in an "execution context." This context is defined by three different characteristics:

• Variables environment
• Lexical environment
• This-scope binding

As we've seen in the last few blog posts, the lexical environment is quite powerful when it comes to closures. It allows us to retain references to define-time values, even after our closures have been passed out of scope. Up until now, we've not had to worry about any THIS-scope binding since all of our code has been written without ColdFusion components. If I've learned anything from JavaScript, however, it's that the THIS scope is never as simple as you'd like it to be. For this post, I want to explore the binding of the THIS scope when closures are used in conjunction with ColdFusion components.

For the first test, all I want to do is see how the THIS and VARIABLES scope are bound to a closure that is defined inside a ColdFusion component. When that closure is passed out of the component, what can it see? To investigate, I've created a simple ColdFusion component that defines an accessor and returns it to the calling context:

Simple.cfc - Our Simple ColdFusion Component

As you can see, this ColdFusion component defines the closure, getter(). This getter then provides tunneling access to the This scope, the Variables scope, and the "Self" scope. Self is just a local variable that points to the This scope. If you've done any coding in JavaScript, you've probably come across this pattern at some point. Since the This scope is dynamically bound in JavaScript, people often create a "self" variable to retain a reference to a specific version of This.

Now, let's create some external code that makes use of this getter():

Here, we are requesting the closure from our Simple.cfc instance. We are then using that closure to access the "value" property from each of the three scopes. When we run this code, we get the following page output:

Public: I am in the THIS scope!!
Private: I am in the VARIABLES scope!!
Self: I am in the THIS scope!!

As you can see, the closure, defined within the ColdFusion component, retained a reference to the appropriate This and Variables scope even when that closure was passed out of context.

But, the closure was defined in a context in which "This" is a meaningful value; and it was then passed into a context in which "This" is not a meaningful value. As such, we can't be quite convinced that the This scope binding was truly put to the test. In order to put this binding through the wringer, we have to pass the closure into a context in which the This scope binding is meaningful. In other words, we have to pass the closure into another ColdFusion component.

For this experiment, I've created another simple ColdFusion component that does nothing but provide potential override values for the This-scope and Variables-scope:

Simple2.cfc - Our Secondary ColdFusion Component

As you can see, this component does almost nothing. That's because our calling code is going to be injecting the above-mentioned getter() method into this new component context. Once the getter() method becomes a property of this secondary component, we can really put the This-binding to the test:

Here, we are repeating the same scope-access test as before; only this time, we are performing it after the closure was transfered from one This-relevant context into another This-relevant context. When we run the above code, we get the following output:

Public: I am in the OVERRIDE THIS scope.
Private: I am in the VARIABLES scope!!
Self: I am in the THIS scope!!

Here's where things start to get a bit more interesting. If you look at the first line of output, you'll notice that the public value - the This-scoped value - came out of the second ColdFusion component, not the first. This means that when the closure was executed in the context of the second component, the runtime binding of THIS was bound to the second component, not to the lexical environment of the closure.

"This" is a magical scope. Its binding is performed just-in-time as functions are executed. We can't depend on the lexical scoping of our closures to retain the appropriate reference. If we need to reference the This scope, we can always use the "Self" pattern. As you can see from the above output, our locally-defined Self reference was able to retain the original This scope reference, even when the This scope was being dynamically bound.

Closures are pretty awesome. They have the ability to retain references to their lexical environment even when they are passed out of scope. This is true even for the define-time page context and the Variables scope. The only thing that seems to break that pattern is the runtime binding of the This scope. This aspect of the execution context is always dynamic, just as it is in JavaScript.

You Might Also Be Interested In: