Skip to content
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.

Sign up for GitHub

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

Jump to bottom

WIP: Implement mutating versions of @set and @lens (#71) #92

Closed
wants to merge 5 commits into from
Closed

WIP: Implement mutating versions of @set and @lens (#71) #92

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
e1387c3
use ConstructionBase
jw3126 Oct 1, 2019
c27c4da
bump version to 0.5.0
jw3126 Oct 2, 2019
d82aef5
Merge branch 'constbase' into bangbang
Oct 8, 2019
a0bd698
add preliminary implementation of #71
Oct 8, 2019
5035991
switch to MutationPolicy
Oct 9, 2019
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
4 changes: 3 additions & 1 deletion Project.toml
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,8 +1,10 @@
name = "Setfield"
uuid = "efcf1570-3423-57d1-acb7-fd33fddbac46"
version = "0.4.1"
version = "0.5.0"

[deps]
BangBang = "198e06fe-97b7-11e9-32a5-e1d131e6ad66"
ConstructionBase = "187b0558-2788-49d3-abe0-74a17ed4e7c9"
MacroTools = "1914dd2f-81c6-5fcd-8719-6d5c9610ff09"

[compat]
Expand Down
3 changes: 2 additions & 1 deletion src/Setfield.jl
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,8 @@
__precompile__(true)
module Setfield
using MacroTools
using MacroTools: isstructdef, splitstructdef, postwalk
using MacroTools: isstructdef, splitstructdef
using BangBang: setproperty!!, setindex!!
Copy link
Collaborator

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!! and setindex!! to ConstructionBase.jl or some small library under JuliaObjects? (Also, we probably should create a new API setproperties!! instead.)

Copy link
Author

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?

Copy link
Collaborator

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

Copy link
Author

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.

Copy link
Author

@colinxs colinxs Oct 8, 2019 •
edited
Loading

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?

Copy link
Author

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 :)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • I am fine with Setfield depending on BangBang temporarily if we have a plan how to fix that in near future.
  • If we move the required things from BangBang to ConstructionBase, how much code/dependencies would that add to ConstructionBase @tkf?
  • I like the idea to split @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.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • I am fine with Setfield depending on BangBang temporarily if we have a plan how to fix that in near future.

I think fixing it (= separating out the base part of BangBang) is hard.

  • If we move the required things from BangBang to ConstructionBase, how much code/dependencies would that add to ConstructionBase

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 have ismutablestruct(::Type{<:StructType}) and even ismutable(::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).

  • But I feel developing this is quite some effort and should be done independently of this PR.

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).

Copy link
Owner

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.

Copy link
Owner

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)


include("lens.jl")
include("sugar.jl")
Expand Down
4 changes: 2 additions & 2 deletions src/experimental.jl
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
module Experimental
using Setfield
using Setfield: constructor_of
using ConstructionBase: constructorof
import Setfield: get, set
export MultiPropertyLens

Expand Down Expand Up @@ -32,7 +32,7 @@ end
end
Expr(:block,
Expr(:meta, :inline),
Expr(:call, :(constructor_of($T)), args...)
Expr(:call, :(constructorof($T)), args...)
)
end

Expand Down
Loading