This function isn't generic, doesn't return an IEnumerable, raises the question why it only works for arrays...
Not great lol
UpdateWhere is a handy function
21–30 of 32 posts
Re: UpdateWhere is a handy function
#22This reminds me of Haskell's 'functor' [1] [1] https://hackage.haskell.org/package/base-4.18.0.0/docs/Data-...
Very much so, it’s a functor instance on some sort of tree, except the `map` includes a conditional dispatch. It’s essentially fmap $ ap fromMaybe Except this doesn’t quite work, I’m sure there’s a pointfree version, best I can achieve is \p -> fmap $ ap fromMaybe p Which takes an `a -> Maybe a` and an `[a]`, and replaces all the values for which the callback returns `Some`, and leaves as-is all the values for which…
You're looking for `fmap . ap fromMaybe`
Re: UpdateWhere is a handy function
#23Clever is bad, boring is good.
As a senior engineer, you see things like this all the time from more junior engineers: way too generic code, done in an overly clever way, incompressible to most. I've spent countless hours telling junior engineers to "dumb it down" and "make it less generic". Not all features that exist must be used. And no, you don't have to combine them all either. That's why I dislike Scala, and like Go. Go has like 3 features, and Scala has 100. It's very hard to make something overly complicated with 3 features (this is hyperbole obviously;I like Scala as a language, but not how many humans use it).
Code is written once, and read 100x, so it must be easy to parse by humans, and easy to understand in a split second. Junior engineers will have to understand it. New team members will have to understand it. If you have the occasional function like this, that's fine. If your entire code looks like this, or you are proud to have written a "clever function", that's not so good.
I try to write dumb code wherever possible. Do the expected, do the boring.
Re: UpdateWhere is a handy function
#24This seems like ramda’s evolve function because it updates with a function instead of a value, and it’s conditional because you’re giving a predicate.
One idea to make this more versatile would be to use a mapping instead of a callable for the whereFn and updateFn in order to simultaneously alter multiple columns of your objects. Also, you could add a path field in order to focus on particular nested paths in your data.
Ultimately, others might be right; this function is intended for use on collections, make sure to avoid using this to enable yourself to have a messy junk drawer of json blobs!
Re: UpdateWhere is a handy function
#25Clever is bad, boring is good. As a senior engineer, you see things like this all the time from more junior engineers: way too generic code, done in an overly clever way, incompressible to most. I've spent countless hours telling junior engineers to "dumb it down" and "make it less generic". Not all features that exist must be used. And no, you don't have to combine them all either. That's why I dislike Scala, and li…
[deleted]
Re: UpdateWhere is a handy function
#26Re: UpdateWhere is a handy function
#27Feels like something had gone very wrong if a function like this is useful. Would only be useful for unstructured data since if you had structure data you could write a more specific function. This can easily match the wrong value and cause problems. And why would it match the wrong value? Because you have unstructured data and it might not be knowable if you might have false positives
I don’t know the domain where this function is used, but stuff like that is used constantly in data science.
df[df[mySelection] == wrongVal] = rightValRe: UpdateWhere is a handy function
#28Feels like something had gone very wrong if a function like this is useful. Would only be useful for unstructured data since if you had structure data you could write a more specific function. This can easily match the wrong value and cause problems. And why would it match the wrong value? Because you have unstructured data and it might not be knowable if you might have false positives
I don't like how it could result in surprises. e.g. you use it to update an array, but there are objects inside, which you accidentally modify. I think these surprises could be reduced if you turn them into explicit parameters in the signature, e.g. export const updateWhere = (whereFn, updatefn, thing, recurseArray=true , recurseObjects=true)
If `thing` contains any cycles then it will explode. E.g.
const thing = {};
thing.self = thing;
const thing = [];
thing.push(thing);
Also any non-enumerable properties that may have been defined on objects are lost.
Basically the function is only suitable for recently parsed JSON.
Re: UpdateWhere is a handy function
#29Re: UpdateWhere is a handy function
#30Feels like something had gone very wrong if a function like this is useful. Would only be useful for unstructured data since if you had structure data you could write a more specific function. This can easily match the wrong value and cause problems. And why would it match the wrong value? Because you have unstructured data and it might not be knowable if you might have false positives
I disagree. For example, It's useful if you have a bunch of cached network requests that each list some resources and you want to update all of the instances of a specific resource (matching by uuid).
So store the requests in a map and each request exposes an update() method.