Do we need MutationPolicy?

[tkf]

Continuing the discussion from #31 (comment)

I thought it was useful for generic programming that supports immutable and mutable types simultaneously. But I never needed it in practice.

Same here :) Meaning that I thought it'd be useful but have never used yet. I'm hoping to use it soon for writing generic code for mutable arrays and StaticArray. So I thought I'd fix it for 0.7. But I'm not entirely sure if I can write such code without handling the difference manually in the end.

Also, for Setfield.jl to be usable in my code (especially with Julia 0.7), dot-fusions like .= and .+= also have to be implemented which would add more complexity.

OTOH I implement custom lenses from time to time and then the MutationPolicy machinery just adds annoying complexity.

Do you mean it's cumbersome to write policy-aware lens? Thinking out loud, how about putting the policy in Lens type? This way, you can define policy-unaware lens. Additional benefit would be that you can compose Lens{EncourageMutation} and Lens{ForbidMutation} in arbitrary nested way.

[jw3126]

Let me get one step back first. If you want to modify an object

1. It is easy if the object is mutable
2. Hard if the object is immutable

So Setfield should initially solve the first problem. Now both are easy. But then I thought there is a third case:

3. Hard if the object may or may not be mutable in generic code

So I thought this case should be covered as well by Setfield and introduced the MutationPolicy mechanism. However I never really needed it and I think it is half baked.

Concerning dot-fusion support, what do you need? Do you want to update things with .= that may or may not be mutable like in 3.? Or do you just need 2. for things like

v = @SVector randn(3)
@set v[1:2] .= 42

For now my preference would be to get rid of support for 3. completely and only reintroduce it (via your suggestion or MutationPolicy or something else) if there is an actual use case that can guide the design.

[tkf]

Thanks for the analysis. Yes, I think it makes sense to get rid of MutationPolicy. If it is possible to implement different mutation policy using type-parameter, it means that I can implement it outside Setfield.jl; I should experiment it myself in/with the package I'm actually using it and then discuss if it makes sense to bring it back to Setfield.jl. Luckily, you already wrote code to do it so probably all I need is to make some type hierarchy and copy-and-paste some code from Setfield.jl 0.1.0. I think it's nice to keep the core simple and extensible.

Do you want to update things with .= that may or may not be mutable like in 3.?

Yes, I meant case 3. But case 2 is a requirement for it, so I also meant to add support for dotted assignments to StaticArrays.

[tkf]

BTW, as you asked me about my usage elsewhere, I just uploaded: https://github.com/tkf/Bifurcations.jl/blob/master/src/diffeq.jl

It's a bifurcation analysis library. Setfield.Lens is one of the core of the API since lens is a really good encoding of "how to change a parameter of the model."

[jw3126]

Cool, I will try it out!

[tkf]

It's still a big mess right now :)

Once it's stabilized, I'll perhaps make a PR to add a section something like "Who uses Setfield.jl" in README and put the link there.