Closures => Context Aware
A closure is the combination of a function and the lexical environment within which that function was declared.
Remember that functions (UDFs) in BoxLang are objects, and closures are objects. So, are closures and functions the same? The answer is yes and no. The main difference between a UDF and a closure is that closures have access to the lexical environment in which they are declared. Both functions and closures can be manipulated at runtime and passed around to other functions and closures or returned from other functions and closures. Phew!
A closure can be used in any of the following ways:
Defined inline without giving a name.
They can be assigned to a variable, array item, struct, and variable scope.
It can be returned directly from a function.
Assigned Closures
If we execute this template via CommandBox, our output will be luis. This means the display
closure has access to its surroundings to display the name
variable. It can manipulate it, add to it, remove from it, and more.
Returned Closures/High-Order Functions
We can also have a function return a closure that can leverage the function's variable environment.
In this case, the makeAdder
creates a function that will add the passed-in variable with another via a delay of execution. You can then execute the resultant closures add
with another number to get your calculation of 3
in this case.
Funky!!
Passed Closures
BoxLang also has the concept of functional programming using several modern operations, like map(), reduce(), filter(), each(), etc
you can pass closures into other functions for operating on different data structures.
Please note that you can construct your very own functional member functions on your objects and generate very functional custom DSL (Domain Specific Languages) by being creative.
Delayed Execution
Another big advantage of leveraging closures for functional programming is that closures are the blueprint of a function and are not executed until you want to. They are useful for delaying execution and great for design patterns like observers, filters, iterators, and much more.
Closure Scopes
A closure retains a copy of variables visible at its creation. The global variables (like BoxLang specific scopes) and the local variables (including declaring or outer function's local and arguments scope) are retained at the time of a closure creation. Functions are static.
The following details the scope of closure based on the way they are defined:
In a class function
Closure argument scope, enclosing function local scope and argument scope, this scope, variable scope, and super scope
In a CFM function
Closure argument scope, enclosing function local scope and argument scope, this scope, variable scope, and super scope
As function argument
Closure argument scope, variable scope, and this scope and super scope (if defined in class).
In a closure, the following is the order of search for an unscoped variable:
Closure's
local
scopeClosure's
arguments
scopeOuter function'
local
scope if availableOwner function's
local
scope if availableBoxLang built-in scope
isClosure()
BoxLang has a built-in function called isClosure()
that allows you to evaluate if a variable is a closure or not:
Lambda Expressions or Arrow Functions
Please note that they are not REAL lambdas or pure functions. Pure functions are not supposed to interact with their environment and should have no side effects on their surroundings. However, in BoxLang, they are just implemented using the expression syntax, not the semantic nature of pure functions.
Arrow functions reduce much of the syntax around creating closures. In its simplest form, you can eliminate the function
keywords, curly braces, and return
statements. Arrow expressions implicitly return the results of the expression body.
A simple arrow expression with multiple arguments:
A complex arrow expression with an argument:
Last updated