G'day:
As I mentioned yesterday ("CFML: tag-based versions of some script-based code") I've been asked by a couple of people to show the tag-based version of the script-based CFML code. This has ben particularly in reference to my typical approach of using higher-order functions to perform data transformation operations on iterable objects (eg: arrays, structs, lists, etc). Here I will briefly do that for some examples of using mapping functions. The process is the same each time, so I'll not dwell on it too much.
I have already written about the nuts and bolts of mapping higher-order functions in CFML back in 2014 in "ColdFusion 11: .map() and .reduce()". I also looked at how to implement arrayMap in older versions of CFML: "arrayMap(): a reverse CFML history".
In short, these collection-iteration higher order functions work on the premise that most looping operations exist solely to perform data transformation, and it makes sense to encapsulate that into a function, rather than having to hand-crank it. Obviously every data transformation is specific to its circumstance, so the collection-iteration functions take a callback as an argument (thus making them higher-order functions), where the callback defines the data transformation operation. Taking this approach makes the code clearer as to what the intent of the transformation is, and also encapsuates the implementation in its own functions, so its variables are all well encapsulated and don't impact the rest of the calling code. It's just a tider way of doing data transformation.
A mapping operation takes one collection and remaps the values for each key into a different value. The keys and the overall size and order (if it has a sense of order) of the collection is preserved. Also the original collection is not altered; an entirely new collection is returned.
That's enough of an explanation. This article is about comparing code styles. Here goes.
keys = ["ONE", "TWO", "THREE", "FOUR"]
translationLookup = {
"ONE" = {mi = "tahi", jp = "一"},
"TWO" = {mi = "rua", jp = "二"},
"THREE" = {mi = "toru", jp = "三"},
"FOUR" = {mi = "wha", jp = "四"}
}
maori = keys.map((key) => translationLookup[key].mi)
writeDump(maori)
Here we have a one-liner that takes an array of translation keys and maps them to their actual translations.
Equivalent tag-based code is a bit more effort. We need to hand-crank our array construction:
<cfset japanese = []>
<cfloop array="#keys#" item="key">
<cfset arrayAppend(japanese, translationLookup[key].jp)>
</cfloop>
<cfdump var="#japanese#">
In the next example I am being less literal about the "key mapping" idea, in case one got a sense that that sort of thing is inate to a mapping operation. I'm doubling each element in the array:
values = [1, 22, 333, 4444]
doubled = values.map((n) => n*2)
writeDump(doubled)
And the tags version (although here I'm halvig the values, for the hell of it). Same as the previous exercise really: just a wee bit clunkier than using the dedicated mapping function:
<cfset halved = []>
<cfloop array="#values#" item="value">
<cfset arrayAppend(halved, value / 2)>
</cfloop>
<cfdump var="#halved#">
A more real-world example would be when yer getting an array of raw data values back from some sort of data-retrieval operation, and you want to properly model those as objects before returning them to your business logic:
records = [
{id=1, mi="whero", en="red"},
{id=2, mi="kakariki", en="green"},
{id=3, mi="kikorangi", en="blue"}
]
objects = records.map((record) => new Colour(record.id, record.mi, record.en))
vs:
<cfset objects = []>
<cfloop array="#records#" item="record">
<cfset arrayAppend(objects, new Colour(record.id, record.mi, record.en))>
</cfloop>
<cfdump var="#objects#">
You get the idea.
To show how strings can be remapped too, I knocked-together a quick example of String.map, but then remembered Lucee does not support String.map yet, so needed to use a list instead:
s = "The Quick Brown Fox Jumps Over The Lazy Dog"
a = asc("a")
z = asc("z")
rot13 = s.listToArray("").map((c) => {
var checkCode = asc(lcase(c))
if (checkCode < a || checkCode > z) {
return c
}
var offset = (checkCode + 13) <= z ? 13 : -13
return chr(asc(c) + offset)
}).toList("")
writeOutput(rot13)
And I tested this by feeding the result back into a tag-based version of the operation, to make sure it returned to the original string:
<cfset a = asc("a")>
<cfset z = asc("z")>
<cfset s2 = "">
<cfloop array="#listToArray(rot13, "")#" item="c">
<cfset checkCode = asc(lcase(c))>
<cfif checkCode LT a OR checkCode GT z>
<cfset s2 &= c>
<cfcontinue>
</cfif>
<cfset offset = 13>
<cfif checkCode + 13 GT z>
<cfset offset = -13>
</cfif>
<cfset s2 &= chr(asc(c) + offset)>
</cfloop>
<cfoutput>#s2#</cfoutput>
All in all using the specific iteration function is slightly clearer as to what sort of transformation is taking place, plus it saves you from having to write the looping and assignment scaffolding that a tags-based / hand-cranked version might. Often remappings are one-liners, and it's just more readable to do it as a simple assignment epression than having to hand-crank the boilerplate looping code.
The code for this article is all munged together in public/nonWheelsTests/higherOrderFunctionsDemonstration.
I'll have a look at how reduce operations work, tomorrow.
Righto.
--
Adam
