Why, I wonder, did the CF Team implement

arrayReduceRight

and

stringReduceRight

, but not

structReduceRight

, and

queryReduceRight

? Any thoughts, @Mark Takata (Adobe)?

Since yesterday you got me looking into some Java classes and I wonder why CF doesn’t have Infinity, or HashSet.

there's plenty of shit it dun't have. But the things I mention represent kind of a break in the CFML collection "API" (such as it is). ie: if one collection type has reduceRight... all the rest should too.

since struct is unordered would reduceRight make sense? query doesn't have that issue (and of course they also introduced ordered structs, so...)

and

listReduceRight

?

off the top of my head, if I was a bettin person, I'd say probably because the underlying structures are not implemented in the same way and use the "wrong" Java objects. But if those are interesting and useful, we should probably see about implementing them. The next version is pretty language-light (outside of adding GraphQL, which you're either incredibly excited about or don't give two ducks, there's no in between lol) so maybe we can lean in on 2025 and fill in a lot of those gaps.

Didn't even know

reduceRight

was a thing until just now. So it is just a Reduce, but run from right-to-left for arrays (

arrayReduceRight

) and strings (

stringReduceRight

)?

The fact that structs have no guaranteed order (by default), I think makes a good argument for why you wouldn't have native support for reduce right/left, because in a default scenario, it's not going to work as you might expect. I suppose they could throw exceptions when the structs are not ordered, but I can see why inclusion would probably cause confusion for many.

CFML already does support "left" reduce (ie: vanilla

structReduce

). Poss you have not read the thread thoroughly.

I could see it as two interfaces: Collection implements reduce, and OrderedCollection implements reduceRight.