-
Notifications
You must be signed in to change notification settings - Fork 17
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
WIP: Implement mutating versions of @set and @lens (#71) #92
Changes from 4 commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,7 +1,10 @@ | ||
export Lens, set, get, modify | ||
export @lens | ||
export set, get, modify | ||
using ConstructionBase | ||
export setproperties | ||
export constructorof | ||
|
||
|
||
import Base: get | ||
using Base: setindex, getproperty | ||
|
@@ -81,6 +84,11 @@ Replace a deeply nested part of `obj` by `val`. See also [`Lens`](@ref). | |
""" | ||
function set end | ||
|
||
abstract type BangStyle end | ||
struct NoBang <: BangStyle end | ||
struct OneBang <: BangStyle end | ||
struct TwoBang <: BangStyle end | ||
|
||
@inline function modify(f, obj, l::Lens) | ||
old_val = get(obj, l) | ||
new_val = f(old_val) | ||
|
@@ -92,8 +100,10 @@ get(obj, ::IdentityLens) = obj | |
set(obj, ::IdentityLens, val) = val | ||
|
||
struct PropertyLens{fieldname} <: Lens end | ||
struct PropertyLens!{fieldname} <: Lens end | ||
struct PropertyLens!!{fieldname} <: Lens end | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would implement it using something like this: abstract type MutationPolicy end
struct Immutable <: MutationPolicy end # no bang
struct AlwaysMutate <: MutationPolicy end # !
struct TryMutate <: MutationPolicy end # !!
struct PropertyLens{fieldname, TP <: MutationPolicy} <: Lens
policy::TP
end
PropertyLens(fieldname, policy = Immutable()) =
PropertyLens{fieldname, typeof(policy)}(policy) It would also be handy define accessor functions MutationPolicy(::Lens) = Immutable() # should it be this?
MutationPolicy(l::PropertyLens) = l.policy There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah that seems more concise (and also replaces the fairly redundant struct PropertyLens{fieldname, TP} end
PropertyLens(fieldname, policy::MutationPolicy = Immutable()) = PropertyLens{fieldname, policy}()
MutationPolicy(::PropertyLens{<:Any, TP}) = TP Also, just curious, what does There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
It would be a singleton if struct Demo1 end
struct Demo2{T}
demo::T
end
julia> sizeof(Demo2(Demo1()))
julia> Base.issingletontype(typeof(Demo2(Demo1())))
true If we want to enforce the policy to be a singleton, I think your approach would be better.
I was thinking Type-of-Policy. It can have a better name, too :) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Ahh, I didn't know that! I was operating off of the definition in the docs:
which I took to imply "singleton if-and-only-if immutable composite type with no fields". Thanks for the explanation! Perhaps There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe? We can also call it simply There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like the verbosity. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
|
||
|
||
function get(obj, l::PropertyLens{field}) where {field} | ||
function get(obj, l::Union{PropertyLens{field}, PropertyLens!{field}, PropertyLens!!{field}}) where {field} | ||
getproperty(obj, field) | ||
end | ||
|
||
|
@@ -103,66 +113,9 @@ end | |
:(setproperties(obj, ($field=val,))) | ||
) | ||
end | ||
@inline set(obj, l::PropertyLens!{field}, val) where {field} = setproperty!(obj, field, val) | ||
@inline set(obj, l::PropertyLens!!{field}, val) where {field} = setproperty!!(obj, field, val) | ||
|
||
@generated constructor_of(::Type{T}) where T = | ||
getfield(parentmodule(T), nameof(T)) | ||
|
||
function assert_hasfields(T, fnames) | ||
for fname in fnames | ||
if !(fname in fieldnames(T)) | ||
msg = "$T has no field $fname" | ||
throw(ArgumentError(msg)) | ||
end | ||
end | ||
end | ||
|
||
""" | ||
setproperties(obj, patch) | ||
|
||
Return a copy of `obj` with attributes updates accoring to `patch`. | ||
|
||
# Examples | ||
```jldoctest | ||
julia> using Setfield | ||
|
||
julia> struct S;a;b;c; end | ||
|
||
julia> s = S(1,2,3) | ||
S(1, 2, 3) | ||
|
||
julia> setproperties(s, (a=10,c=4)) | ||
S(10, 2, 4) | ||
|
||
julia> setproperties((a=1,c=2,b=3), (a=10,c=4)) | ||
(a = 10, c = 4, b = 3) | ||
``` | ||
""" | ||
function setproperties end | ||
|
||
@generated function setproperties(obj, patch) | ||
assert_hasfields(obj, fieldnames(patch)) | ||
args = map(fieldnames(obj)) do fn | ||
if fn in fieldnames(patch) | ||
:(patch.$fn) | ||
else | ||
:(obj.$fn) | ||
end | ||
end | ||
Expr(:block, | ||
Expr(:meta, :inline), | ||
Expr(:call,:(constructor_of($obj)), args...) | ||
) | ||
end | ||
|
||
@generated function setproperties(obj::NamedTuple, patch) | ||
# this function is only generated to force the following check | ||
# at compile time | ||
assert_hasfields(obj, fieldnames(patch)) | ||
Expr(:block, | ||
Expr(:meta, :inline), | ||
:(merge(obj, patch)) | ||
) | ||
end | ||
|
||
struct ComposedLens{LO, LI} <: Lens | ||
outer::LO | ||
|
@@ -219,13 +172,26 @@ end | |
struct IndexLens{I <: Tuple} <: Lens | ||
indices::I | ||
end | ||
struct IndexLens!{I <: Tuple} <: Lens | ||
indices::I | ||
end | ||
struct IndexLens!!{I <: Tuple} <: Lens | ||
indices::I | ||
end | ||
|
||
Base.@propagate_inbounds function get(obj, l::IndexLens) | ||
Base.@propagate_inbounds function get(obj, l::Union{IndexLens, IndexLens!, IndexLens!!}) | ||
getindex(obj, l.indices...) | ||
end | ||
|
||
Base.@propagate_inbounds function set(obj, l::IndexLens, val) | ||
setindex(obj, val, l.indices...) | ||
end | ||
Base.@propagate_inbounds function set(obj, l::IndexLens!, val) | ||
setindex!(obj, val, l.indices...) | ||
end | ||
Base.@propagate_inbounds function set(obj, l::IndexLens!!, val) | ||
setindex!!(obj, val, l.indices...) | ||
end | ||
|
||
""" | ||
ConstIndexLens{I} | ||
|
@@ -251,14 +217,21 @@ true | |
``` | ||
""" | ||
struct ConstIndexLens{I} <: Lens end | ||
struct ConstIndexLens!{I} <: Lens end | ||
struct ConstIndexLens!!{I} <: Lens end | ||
|
||
Base.@propagate_inbounds get(obj, ::ConstIndexLens{I}) where I = obj[I...] | ||
Base.@propagate_inbounds get(obj, ::Union{ConstIndexLens{I}, ConstIndexLens!{I}, ConstIndexLens!!{I}}) where I = obj[I...] | ||
|
||
Base.@propagate_inbounds set(obj, ::ConstIndexLens{I}, val) where I = | ||
setindex(obj, val, I...) | ||
Base.@propagate_inbounds set(obj, ::ConstIndexLens!{I}, val) where I = | ||
setindex!(obj, val, I...) | ||
Base.@propagate_inbounds set(obj, ::ConstIndexLens!!{I}, val) where I = | ||
setindex!!(obj, val, I...) | ||
|
||
# TODO: Do we want/need !/!! for ConstIndexLens? If so, should below also include !! lens? | ||
@generated function set(obj::Union{Tuple, NamedTuple}, | ||
::ConstIndexLens{I}, | ||
::Union{ConstIndexLens{I}, ConstIndexLens!!{I}}, | ||
val) where I | ||
if length(I) == 1 | ||
n, = I | ||
|
@@ -278,15 +251,6 @@ Base.@propagate_inbounds set(obj, ::ConstIndexLens{I}, val) where I = | |
end | ||
end | ||
|
||
struct DynamicIndexLens{F} <: Lens | ||
f::F | ||
end | ||
|
||
Base.@propagate_inbounds get(obj, I::DynamicIndexLens) = obj[I.f(obj)...] | ||
|
||
Base.@propagate_inbounds set(obj, I::DynamicIndexLens, val) = | ||
setindex(obj, val, I.f(obj)...) | ||
|
||
""" | ||
FunctionLens(f) | ||
@lens f(_) | ||
|
@@ -333,6 +297,7 @@ FunctionLens(f) = FunctionLens{f}() | |
|
||
get(obj, ::FunctionLens{f}) where f = f(obj) | ||
|
||
Base.@deprecate constructor_of(T) constructorof(T) | ||
Base.@deprecate get(lens::Lens, obj) get(obj, lens) | ||
Base.@deprecate set(lens::Lens, obj, val) set(obj, lens, val) | ||
Base.@deprecate modify(f, lens::Lens, obj) modify(f, obj, lens) |
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.
BangBang is not a super small library and it probably will accumulate more code over time, as it has to re-implement some Base/stdlib functions. I'm not sure if it is a good approach for Setfield.jl to depend on it. Maybe we should factor out
setproperty!!
andsetindex!!
to ConstructionBase.jl or some small library under JuliaObjects? (Also, we probably should create a new APIsetproperties!!
instead.)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.
Makes sense! What's your timeline on registering ConstructionBase.jl?
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.
We are just waiting for it JuliaRegistries/General#4063
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.
Oh, awesome!! Glad to hear.
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.
If we do refactor, need that block this PR? I'm happy to make the changes, just looking to get this merged sooner-than-later so I can start developing around it :).
Also, is #91 just waiting on JuliaRegistries/General#4063?
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.
Just pushed the changes to use
MutationPolicy
.In principal, I like the idea of making Setfield extensible. At one point I was considering manipulating deeply nested C structs using
unsafe_store!
for cases where (1) the compiler can't optimize away object construction and (2) thread-safe field manipulation. I recently found mchristianl/MemoryMutate.jl which does just this and could be re-implemented in terms of Setfield.jl.The separation of BangBang is obviously up to you all.
My selfish opinion would be if you want to refactor BangBang, then make Setfield extensible, otherwise either is fine :)
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.
Setfield
depending onBangBang
temporarily if we have a plan how to fix that in near future.BangBang
toConstructionBase
, how much code/dependencies would that add toConstructionBase
@tkf?@set
more cleanly in a "parsing" step and an "interpretation" step that can be overloaded by other macros. But I feel developing this is quite some effort and should be done independently of this PR.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.
I think fixing it (= separating out the base part of
BangBang
) is hard.Reviewing my code in BangBang.jl, I realized that there are quite a few interface methods in BangBang.jl (
may
,possible
,pure
,ismutable
,ismutablestruct
, and_asbb
). I think it would be too much to add those methods as-is in ConstructionBase.jl. (Although I think it makes sense to haveismutablestruct(::Type{<:StructType})
and evenismutable(::Type{<:CollectionType})
there.) What ConstructionBase.jl has at the moment are a few functions that are definitely the basic things you want. However, I feel what BangBang.jl has are rather opinionated set of functions (even though I think this is a nice direction to explore).I do agree this is a hard task. But I think it's the most reasonable option for implementing
@set!!
and@set!
(If I were forced choose refactoring BangBang.jl or making Setfield.jl extensible, I'll definitely choose the latter).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.
I did a POC here.
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.
I responed JuliaObjects/ConstructionBase.jl#25 (comment)