-
Notifications
You must be signed in to change notification settings - Fork 19
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
multi-argument modify #130
Comments
Yes, I think we can have this. I don't love the options we have for the signature though: modify(f, optic, objs...) # clashes with existing modify(f, obj, optic)
modify(f, obj1, optic, objs...) # a bit ugly to have the optic in between
modify(f, objs..., optic) # a bit cumbersome for dispatch Alternative we could use a new function for this. |
Note that So there's probably nothing too wrong with the |
That is a good point, now I am more happy with the signature |
After some usage I quite like it, and may make a PR here soon :) The one inconvenience I noticed is: julia> obj = (name="A", values=(red=1, blue=2))
julia> sensitivities = (red=2, green=4, blue=3)
# want to modify obj.values according to sensitivities
# seems straightforward?..
julia> modify(/, obj.values, ∗ₚ, sensitivities)
(red = 0.5, blue = 0.6666666666666666)
# ... but if I want the full obj back, I need manually nested modify calls:
julia> @modify(obj.values) do values
modify(/, values, ∗ₚ, sensitivities)
end
(name = "A", values = (red = 0.5, blue = 0.6666666666666666)) Some kind of "focusing" optic would seem useful here, but I'm curious what you think about this. |
I knew I saw it somewhere before but forgot, and now found a discussion by @jw3126 in the Setfield repo – jw3126/Setfield.jl#137 :)
I added this feature to AccessorsExtra a few month ago, turns out to be useful sometimes.
Examples:
Implementation is very simple in https://gitlab.com/aplavin/AccessorsExtra.jl/-/blob/master/src/modifymany.jl. Most of the lines are to handle Elements and Properties.
First, I wonder if you have any suggestions on the interface. Is that useful for what you had in mind?
Second, if this is considered generally within the Accessors scope, we can add it here. Wonder if this is widely useful (I think so, but not without promoting these features...), and worry a bit about "feature creep" of such a foundational package. In comparison, AccessorsExtra contains less clear-cut stuff anyways, so I'm much less worried there :)
The text was updated successfully, but these errors were encountered: