You Can Modify Elements During Filtering In ColdFusion

I dunno... the fact that the modification affects both the original Users and the listedUsers arrays, but the filter only affects the newly created listUsers array just seems... wrong... to MY ignorant little caveman brain.

I meant "filteredUsers", not "listedUsers" (I guess you can't edit!)🙂

Hallo mate. I think you're missing the whole "use the right too for the job" concept, and also forgetting... you're not the only person who will be reading your code.

map, filter, reduce etc have meanings as concepts, so when someone else sees your code and see that it filters (BECAUSE YOU ARE CALLING FILTER), they will expect it to a) filter; b) not have side effects; c) not also kinda do a map. Your code is breaking the principle of least astonishment, which is... not as good as it could be.

In yours first example you could use less "astonishing" code by taking the time to understand that the task at hand is to filter out some records, and remap the good ones:

namedUsers = users
    .filter((user) => user.firstName.len() && user.lastName.len())
    .map((user) => user.insert("name", "#user.firstName# #user.lastName#"))

In your second example, yer using input users to do two things: remap the good ones, and tally the bad ones. This is a reduction to me: translate one data structure into another.

namedUsersWithMetrics = users.reduce((metrics, user) => {
    if (user.firstName.len() && user.lastName.len()) {
        user.name = "#user.firstName# #user.lastName#"

        metrics.users.append(user)
        return metrics
    }

    if (!user.firstName.len()) {
        metrics.missingFirstName++
    }
    if (!user.lastName.len()) {
        metrics.missingLastName++
    }

    return metrics
}, {
    missingFirstName  = 0,
    missingLastName = 0,
    users = []
})

(this also fixes the logic error in your example).

You are taking yer hammer and going "ooh look! A Nail!". But if you thought about things some more, you'd see it's not a nail. And it's also not a hammer.

I think you could do with applying some "developer humility" to your approach to these things. When there's an industry-adopted principle, and you think you see where it's wrong or could be improved by doing things "The Nadel Way"... you're probably mistaken because these principles almost certainly exist for a reason and were arrived at by ppl cleverer than you or me.

--
Adam

Code: https://trycf.com/gist/df955c09f7960812c42862714fa4c076/acf2023?theme=monokai

Ben - but you can see the base values at the top with reduce or am I misunderstanding?

namedUsersWithMetrics = users.reduce( ( metrics={ missingFirstName = 0, missingLastName = 0, users = [] }, user ) => {
	if (user.firstName.len() && user.lastName.len()) {
		user.name = "#user.firstName# #user.lastName#"

		metrics.users.append(user)
		return metrics
	}

	if (!user.firstName.len()) {
		metrics.missingFirstName++
	}
	if (!user.lastName.len()) {
		metrics.missingLastName++
	}

	return metrics
} );

You need to be aware of situations where you attempt to reduce an empty array. In Adam's example with the trailing default, namedUsersWithMetrics will equal the default when the array is empty. However, in my example, where the default is set up top, namedUsersWithMetrics will be NULL.

I think a lot of that comes from the initial value being defined below the logic of the loop

So... init it first! Blimey.

Building on what I had before:
https://trycf.com/gist/6bdd830c62fe795f9a394061a29822b4/acf2023?theme=monokai

namedUsersWithMetrics = (()=>{
    var initialState = {
        missingFirstName  = 0,
        missingLastName = 0,
        users = []
    }
    return users.reduce((metrics, user) => {
        user.firstName.len() ?: metrics.missingFirstName++
        user.lastName.len() ?: metrics.missingLastName++

        if (user.firstName.len() && user.lastName.len()) {
            metrics.users.append(user.insert("name", "#user.firstName# #user.lastName#"))
        }

        return metrics
    }, initialState)
})()

One doesn't need the IIFE here, but I figured it was a nice thought when creating what amounts to be a throw-away variable.

90% of cases, I look at the code and feel like it never reads as well as a for loop would read

Indeed. But this is not the point we're making here.

The point is "don't use filter for something that is not a filter operation. In this case your operation is translating one data struct to another, so... in higher-order-function situations: it's not a filter, it's a reduce. My code example demonstrates how to do the reduce operation, in a HOF-semantic way.

Would I use the code above? probably not: I'd use a for loop.

But I would use a for loop. Not a filter. It's not a filter.

Your post on such an interesting subject has left me speechless. I regularly check out your blogs and stay current by reading the material that you offer; nevertheless, the blog that you have posted today is the one that I appreciate the most.