It appears that the sortOrder parameter to arraySort() is being ignored when I use a closure function. Here’s a gist:
Is this by design? I can get it to work the way I want by changing the return values, but this seems like a bug to me, or the documentation needs to mention this.
I’d say that was a documentation bug. If you’re providing a closure, there’s an expectation that you’re explicitly defining the sort order in that logic.
When you provide the return value as described in the docs, you should be able to change the sortOrder param and it should work. Happy to do it according to the docs, but this would be the first time I would have to hard code the sort order of a compare function.
I mean, from a practical standpoint, I’m sure you have just switched your -1 and 1 around already, right? No sense waiting for a Lucee bug fix for it.
Just a question after that of whether the Lucee devs decide to change the docs or change the code behaviour. My gut would be that the additional argument does not make much sense when supplying a UDF as you have full control over the order when using that.
Yes, I adjusted my closure and I’m not waiting on a change. I have to say, just for the sake of argument, I don’t love the API for this function. The following snippet is a common pattern… the caller passes in the sort order and the closure code does not change. However, I do realize I can accomplish the same thing by referencing the options within the closure function, and then the closure logic would be different.
function sortMyData (myDataArray, options) {
// copy/validate options
var options = {
order: "asc"
}
structAppend(options, arguments.options);
// sort the array
arraySort(myDataArray, function (a, b) {
if (a.count < b.count) {
return -1;
}
if (a.count > b.count) {
return 1;
}
return 0;
}, options.order);
} // sortMyData()