Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Understanding immutable composite types with fields of mutable types in Julia

Initial note: I'm working in Julia, but this question probably applies to many languages.

Setup: I have a composite type as follows:

type MyType
    x::Vector{String}
end

I write some methods to act on MyType. For example, I write a method that allows me to insert a new element in x, e.g. function insert!(d::MyType, itemToInsert::String).

Question: Should MyType be mutable or immutable?

My understanding: I've read the Julia docs on this, as well as more general (and highly upvoted) questions on Stackoverflow (e.g. here or here), but I still don't really have a good handle on what it means to be mutable/immutable from a practical perspective (especially for the case of an immutable composite type, containing a mutable array of immutable types!)

Nonetheless, here is my attempt: If MyType is immutable, then it means that the field x must always point to the same object. That object itself (a vector of Strings) is mutable, so it is perfectly okay for me to insert new elements into it. What I am not allowed to do is try and alter MyType so that the field x points to an entirely different object. For example, methods that do the following are okay:

MyType.x[1] = "NewValue"
push!(MyType.x, "NewElementToAdd")

But methods that do the following are not okay:

MyType.x = ["a", "different", "string", "array"]

Is this right? Also, is the idea that the object that an immutable types field values are locked to are those that are created within the constructor?

Final Point: I apologise if this appears to duplicate other questions on SO. As stated, I have looked through them and wasn't able to get the understanding that I was after.

like image 951
Colin T Bowers Avatar asked Dec 09 '14 03:12

Colin T Bowers


1 Answers

So here is something mind bending to consider (at least to me):

julia> immutable Foo
         data::Vector{Float64}
       end

julia> x = Foo([1.0, 2.0, 4.0])
Foo([1.0,2.0,4.0])

julia> append!(x.data, x.data); pointer(x.data)
Ptr{Float64} @0x00007ffbc3332018

julia> append!(x.data, x.data); pointer(x.data)
Ptr{Float64} @0x00007ffbc296ac28

julia> append!(x.data, x.data); pointer(x.data)
Ptr{Float64} @0x00007ffbc34809d8

So the data address is actually changing as the vector grows and needs to be reallocated! But - you can't change data yourself, as you point out.

I'm not sure there is a 100% right answer is really. I primarily use immutable for simple types like the Complex example in the docs in some performance critical situations, and I do it for "defensive programming" reasons, e.g. the code has no need to write to the fields of this type so I make it an error to do so. They are a good choice IMO whenever the type is a sort of an extension of a number, e.g. Complex, RGBColor, and I use them in place of tuples, as a kind of named tuple (tuples don't seem to perform well with Julia right now anyway, wheres immutable types perform excellently).

like image 150
IainDunning Avatar answered Oct 01 '22 10:10

IainDunning