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
add constructorof for Dict #47
Conversation
Codecov Report
@@ Coverage Diff @@
## master #47 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 3 3
Lines 71 74 +3
=========================================
+ Hits 71 74 +3
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This one is a bit tricky since the fields of Dict
are mostly private and I am not familiar with the implementation of Dict
. But I think doing something like d3 = setproperties(d1, keys=["x", "y"])
can easily result in a buggy dict. What is you use case?
I think this PR is useful and wouldn't have consistency issues if defined with some restrictions. I actually tried recently So, something like this would make sense: function setproperties(d::Dict, patch::NamedTuple{(:vals,)})
K = keytype(d)
V = eltype(patch.vals)
Dict{K,V}(d.slots, d.keys, patch.vals, d.ndel, d.count, d.age, d.idxfloor, d.maxprobe)
end |
@aplavin, this is better than exposing all internals, but even the |
I'm not really arguing this should be included into |
Ah thanks for the explanation that makes sense! I guess then I would still take the function lens approach: _vals(d::Dict) = d.vals
Accessors.set(d::Dict, ::typeof(_vals), new_vals) = ... |
Regarding Accessors, I've also wondered whether For this reason, I've earlier added the |
Ah yeah that is a much better approach. I think |
Allows setting
Dict
fields.