mutable fields in Julia struct

19
votes

I couldn't find an answer in both stackoverflow and the Julia docs to the following "design problem":

Let's say I want to define the following object

struct Person
birthplace::String
age::Int
end

Since Person is immutable, I'm happy that nobody can change the birthplace of any Person created, nonetheless, this also implies that when time passes, I cannot change their age either...

On the other hand, if I define the type Person as

mutable struct Person
birthplace::String
age::Int
end

I can now make them age, but I don't have the safety I had before on the birthplace, anyone can access it and change it.

The workaround I found so far is the following

struct Person
birthplace::String
age::Vector{Int}
end

where obviously age is a 1-element Vector.
I find this solution quite ugly and definitely suboptimal as I have to access the age with the square brackets every time.

Is there any other, more elegant, way to have both immutable and mutable fields in an object?

Maybe the problem is that I am missing the true value of having either everything mutable or immutable within a struct. If that's the case, could you explain me that?

2
structjuliaimmutabilitymutable
from the way you phrase the question I assume you don't care for a incrementage function that creates a new object with the right age? e.g. incrementage(p::Person) = Person(p.birthplace, p.age+1); - Tasos Papastylianou
Exactly, I don't want to create a new object. The idea is a an object that fetches from the web some info and updates some of its fields.. Since it's gonna poll every 10 seconds or so, creating a new object every time is not what I am looking for.. But thanks anyway! - stefabat
you could go down a route with a bespoke inner constructor giving you complete control over what is and is not visible / mutable, like here: stackoverflow.com/q/39133424/4183191 (disclaimer: shameless plug of own question) - Tasos Papastylianou
Nice! I am actually coming from C++, thus I am used to that "type" of objects. But it is definitely not in the philosophy of the language, thus I'll not go down that road. - stefabat

2 Answers

20
votes

For this particular example it seems better to store the birthdate rather than the age, since the birthdate is also immutable, and it is simple enough to calculate the age from that information, but perhaps this is just a toy example.

I find this solution quite ugly and definitely suboptimal as I have to access the age with the square brackets every time.

Usually you would define a getter, i.e. something like age(p::Person) = p.age[1] that you use instead of accessing the field directly. With this you avoid the "ugliness" with the brackets.

In this case, where we only want to store a single value, it is also possible to use a Ref (or possibly a 0-dimensional Array), something like:

struct Person
    birthplace::String
    age::Base.RefValue{Int}
end
Person(b::String, age::Int) = Person(b, Ref(age))
age(p::Person) = p.age[]

with usage:

julia> p = Person("earth", 20)
Person("earth", 20)

julia> age(p)
20
8
votes

You've received some interesting answers, and for the "toy example" case, I like the solution of storing the birth-date. But for more general cases, I can think of another approach that might be useful. Define Age as its own mutable struct, and Person as an immutable struct. That is:

julia> mutable struct Age ; age::Int ; end

julia> struct Person ; birthplace::String ; age::Age ; end

julia> x = Person("Sydney", Age(10))
Person("Sydney", Age(10))

julia> x.age.age = 11
11

julia> x
Person("Sydney", Age(11))

julia> x.birthplace = "Melbourne"
ERROR: type Person is immutable

julia> x.age = Age(12)
ERROR: type Person is immutable

Note that I can't alter either field of Person, but I can alter the age by directly accessing the age field in the mutable struct Age. You could define an accessor function for this, ie:

set_age!(x::Person, newage::Int) = (x.age.age = newage)

julia> set_age!(x, 12)
12

julia> x
Person("Sydney", Age(12))

There is nothing wrong with the Vector solution discussed in another answer. It is essentially accomplishing the same thing, since array elements are mutable. But I think the above solution is neater.