Let’s say I want variable b to update with variable a.
a = [42]
b = a
a[1] = 69
Now b would be 69.
This works but seems rather ugly. Is there a more intuitive way?
It’s not exactly clear what you’re looking for. Could you give more context, a more complete example that would illustrate what problem you’re trying to solve.
If you just want a one-element Vector, try Ref:
a = 42
b = a
a = 69
b
Result: 42
Wanted: 69
What does Ref() do?
Perhaps a demonstration will be clearest:
julia> a = Ref(42)
Base.RefValue{Int64}(42)
julia> b = a
Base.RefValue{Int64}(42)
julia> a[] = 69
69
julia> a
Base.RefValue{Int64}(69)
julia> b[]
69
julia> b
Base.RefValue{Int64}(69)
julia> a === b
true
An important bit to note is that a Ref needs to be deReferenced to get the value using the b[] notation.
6 Likes
Thank you, this helped a lot to understand.
Actually I wanted to implement a dynamic range like this:
x = Ref(1)
r = x:x+9
x[] = 3
Expected: 3:12
Unfortunately RefValues do not work with functions like this. Any ideas?
You can do that with Observables.jl:
julia> using Observables
julia> x = Observable(1)
Observable(1)
julia> r = map(xx -> xx:xx+9, x)
Observable(1:10)
julia> r
Observable(1:10)
julia> x[] = 3
3
julia> r
Observable(3:12)
3 Likes
julia> x[] = 3
3
julia> r(x)=x:x+9 # r = x->(:)(x,x+9)
julia> r(x[])
3:12
julia> x[]:x[]+9
3:12
2 Likes
I suggest avoiding such “action at a distance”. It will likely lead to much time debugging unexpected behavior. @rocco_sprmnt21 explicit range construction function is far saner.
1 Like
Maybe Pluto.jl would be of interest? It sets up a reactive notebook so that changing a variable reruns all “downstream” cells to update for the new value.
1 Like
Interesting! I saw people using Pluto, but was wondering why. I will have a look at it.
I wonder if this could lead to issues, once you create the full .jl script and expect it to behave like your notebook did :o
But is this (and your link) a condemnation of reactivity, and of callbacks/listeners/observables/gui-programming? They all rely on “action at a distance”, and it enormously improves the elegance and simplicity of accomplishing this.
Something that’s not acceptable when writing a module might be acceptable for ad-hoc or exploratory tasks.
1 Like
Are you saying that gui creation is inherently ad hoc, or reactivity is only exploratory?
Maybe. I’ve done GUI programming for over 30 years from Xt/Xm callbacks to newer web reactive frameworks, so I know the loose coupling and extensibility benefits of callbacks and event listeners. But I’ve also see complex GUIs with inter-dependencies where getting the event listeners synchronized correctly can be difficult. An extreme example was where I have worked on a large, complex OO system where once the copious and undisciplined use of event listeners led to such a quagmire that some people suggested eliminating event listeners. Doing that would have been impossible, but it highlights the problems that even standard patterns of “action at a distance” can bring. I’m still fairly new to web reactive frameworks, but their typical usage in populating HTML template seems more structured than ad hoc event listeners. I know they exist, but I just haven’t experienced more general reactivity usage patterns yet. Whether callback, event listener, or reactivity, these patterns require judicious, disciplined usage to avoid unmaintainable code.
That said, if the OP had asked a question about event listeners or observables, then I wouldn’t have got the queasy feeling that I did. I see the stated use case more akin to intentionally exposing an OOP class’s internal state and then having some distant code modifying the internal state.
1 Like
Here is a good writeup of an example where an observable workflow can get you into trouble: Makie does not update the plot during an animation - #14 by jules
Like with all design patterns, only use them when they make sense and not because you want to use them.
3 Likes
I have only tried to interpret the intention of the question and find expressions that are closest to the expectations of the asker.
I didn’t have the intention (nor the sufficient general knowledge) to endorse the style or even to suggest alternative routes.
for the rest I try to follow the discussion that ensued and maybe learn some new (for me) concept.