UpdateWhere is a handy function(twitter.com) |
UpdateWhere is a handy function(twitter.com) |
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
> And why would it match the wrong value?
Because you may be searching the tree for something that looks like `(op(const)(const))` to replace it with `(const)`. But that may live many levels deep inside the structure.
Also, from existing names, that seems very close to MapIf (https://resources.wolframcloud.com/FunctionRepository/resour...) just with added recursion.
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) 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.
df[df[mySelection] == wrongVal] = rightValGoing along some previous discussions about jq, and stuff like specter (for Clojure), I do think it would be cool if there were more syntactic niceties for path expressions, extracting data from nested data structures/lists/etc, and applying transformations on them.
Specter can have a "nice DSL" (for certain definitions of nice!) thanks to Clojure's macro functionality. Haskell lenses get somewhere thanks to custom infix operator syntax being a thing. I have yet to see a library that tackles this nicely without those two tools though.
[0]: https://docs.python.org/3/library/ast.html#ast.NodeTransform...
Is this function known by any other name?
I agree with many others in this thread when it comes to this being too specific to be useful and too generic to keep you from shooting yourself in the foot. I would, instead, add this to Array/Object's prototypes and call it on the specific types instead. At least, in that case, you aren't handling multiple fields of concern.
[1] https://www.microsoft.com/en-us/research/wp-content/uploads/...
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.
updateWhere(
thing => thing?.guid === postId,
post => ({...post, title: newTitle}),
networkCache
)
- normalize network responses, so you can get the post directly by id. But this is notoriously painful to do well
- or the code that handles this name change needs to know every request that references the post with that id, and update those titles manually
[1] https://hackage.haskell.org/package/base-4.18.0.0/docs/Data-...
It’s essentially
fmap $ ap fromMaybe
\p -> fmap $ ap fromMaybe p
(I collapsed the `whereFn` and `updateFn` into a single one because there’s no reason not to)
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!
para (\t -> let asIs = (map fst t) in if(whereFn(asIs)) updateFn(asIs) else map snd t)Something is very wrong if you need these.
Get help. Use a hashmap. Plz
Not great lol