Closed yuhan0 closed 3 years ago
You have preempted my work on this :)
I'm not sure about mixing the semantics with unquoting, feels a bit like -<>
if you're familiar
I also think update-many-in
can be generally forgone and update-in->
is sufficient, given that you do a little parsing
I pushed something similar to a branch here https://github.com/bsless/clj-fast/tree/unified-update-in, includes a little cleanup around update-many
Freaky! I guess it was a natural next step in that direction, and an interesting puzzle in any case :)
I agree about the semantics of ~
being iffy, but it was just awkward trying to shove an assoc
in the middle of other update
s, without resorting to something like that const->
macro.
I'm happy to close this PR and go with your implementation :)
Implementing update-many was the natural next step, our implementations are so similar they can be considered siblings.
I think something like const->
is preferable if only because it does not introduce special parsing semantics, but is explicit.
And thank you for the PR and suggestion of assoc-in
, it was a fun brain-teaser
I tried generalising the logic from the recent assoc-in changes, to allow for arbitrary updates to multiple nested keys.
Not sure if I fully understand functional lenses, so there might be a more elegant way of doing this than adding another
updater
parameter. All docstrings are WIP.The proposed API here adds two macros:
update-many
is like clojure.core/update-in but restricted to single-arity functions, whereasupdate-many->
treats the "functions" as threading macro forms so they can be inlined at compile time.I also added a unquoting feature which treats the value as something to be assoc'ed: This could of course be achieved with less magic using
(constantly newval)
or defining something like(defmacro const-> [_ v] v)
to be used in the threading macro.