The Dopefly Tech Blog

<< The Dopefly Tech Blog Main page

Actually understanding closures in ColdFusion 10

posted under category: ColdFusion on March 11, 2012 at 1:00 am by MrNate

There has been a lot of confusion about closures in ColdFusion 10, and I don't think anyone has done a good enough job explaining it. I'm going to try to make it easy.

First, understand that what we call the closures feature is actually a handful of related ideas: anonymous functions, named function expressions, functions as first-class citizens, nested functions, and yes, true closures.

An anonymous function is simply a function without a name. You define it inline, usually as an argument to a function call or as a function's return value. Eventually it may have a name, but at the time and scope of its creation it does not.

A named function expression is another way to define a function. Instead of the classic function operator syntax, function name() {}, you define it a lot like any other variable. Name equals value. var name = function() {};.

Functions as first-class citizens finally reinforces something we have had unofficially since ColdFusion 6.1, passing a function as an argument. The difference now is there is a function data type. This helps us formalize a functional programming paradigm in a previously object-oriented CFML.

Having nested functions means that you can define a function within another. At its most basic, you can categorize you methods, hiding them in another function, and make little helpers that you only call from that defining parent function. You can define them in the classic function operator syntax function name() {} or in the expressed var name = function() {};.

Here is where it gets fun.

That inner function has access to the var scope of the function it was defined from. This is what a closure is. It knows about its origin and it doesn't forget. It will always be tied to that same parent var scope.

Combining those ideas, you can define a function within another and pass it out (with or without assigning a variable name to it), then that outbound function can use its closure abilities to reference data in the method it came from. This is where much of the power of Javascript comes from, and provides a good start to doing functional programming.

The similarities between what CFML will do in CF10 and what Javascript does are incredible. I love the direction we have seen so far, and I am excited for the future of ColdFusion!

Too old to comment!
On Oct 13, 2013 at 1:00 AM Gene (g.en.e whose domain rhymes with said:
Sorry for the very late reply, just read your post now.

I agree that CF10 is moving greatly towards similarity with javascript, which is a very usable thing.

Currently i'm creating a new CF10+ only framework that depends heavily on these new features. It has a pure very lean and mean (front-controller) framework (convention over declaration), very similar to .net's mvc, but more powerfull, less bloat. Furthermore it provides for a meta-modelling definition, from where model, persistency service layers, domain-object services layers, web api stubs + implementations and ultemately multiple views on any given (meta) model can be generated. This all through a ingenious native generation templating system (think T4/code smith but native and way easier/less bloat) , also in the package off course.

However, and that is my point. I only chose CF here, because of my experience with it in a production environment. My programming skills in either javascript or C# (or java for that matter) equal that of CF (Grand master Jedi-grade), but server stability / pitfalls for either node.js nor .net mvc (with its gazillion extentions) are unknown to me. And only because I create this framework as a base for a new application that has to see the light early 2014, my dicision for CF as server side tech, was easily made.

BUT, and that is a big but, since I coded most of the CF layer language agnostic (on purpose off course), I'm going to port its very cool concepts to C# or node.js, for I think they are the future. Adobe doesn't seem to take CF very seriously and I don't think the majority of it's userbase is all that 'compatible' with an architecture that is as dry as a corck and has SOLID written all over it. In my opinion CF will die a sudden death the second it's deparment doesn't show positive financial numbers. That race as I foresee it is one lost against node.js and even .net. PHP or ruby in my opinion are different beasts, attracting different kinds of crazy.

On Oct 13, 2013 at 1:00 AM Gene (g.en.e who spends every waking moment visiting said:
(continues, exceeded the max char limit)

I also plan to publish the framework somewhere in 2014 and then u can decide for yourself if it beats the shit out of anything out there; It will, not only comparing it to the very bad (all of them, yes) frameworks available for CF today. It is build (and tested heavily) towards new tech, SPA-like apps based on angular / BS3 or foundation / web-api (noting Adobe here, that doesn't meet my level of quality, extensibility, easy of use etc etc.), but can be abused for any purpose, including off course old-skool not-so-separation-of-concerns-coding.
Too old to comment!