# Partially mutable object

**URL:** <https://discourse.julialang.org/t/partially-mutable-object/70463>\
**Category:** New to Julia\
**Tags:** struct\
**Created:** [October 27, 2021, 9:30am UTC](https://discourse.julialang.org/t/partially-mutable-object/70463 "2021-10-27T09:30:26Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![Palli](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/palli/32/3380_2.png) [@Palli](https://discourse.julialang.org/u/Palli)\
**Post date:** [October 28, 2021, 10:46pm UTC](https://discourse.julialang.org/t/partially-mutable-object/70463/6 "2021-10-28T22:46:05Z")

</div>

I understand your question, I’m just thinking is it a mistake or anti-pattern to ever do this? So do you have a more concrete example/reason to do this?

If it’s just out of curiosity, and possibly unfamiliarity with Julia (it’s not clear for how long you’ve used Julia), then FYI: `struct`s are immutable (by default) in Julia, ALSO, strictly, in the answers given. I used to like that Julia is an imperative language, i.e. not a pure functional by default.

Maybe @nben’s package can help you:

> [@Announcing Air.jl: STM and immutable collections](https://discourse.julialang.org/t/announcing-air-jl-stm-and-immutable-collections/70361):
>
> Air.jl is a new package for Julia that implements a number of composable multi-threading utilities largely inspired by paradigms from [Clojure](https://clojure.org/). These include: Immutable collections Persistent Dictionaries Persistent Sets Persistent N-Dimensional Arrays Persistent Weighted Dictionaries and Sets (which act as heaps, discrete distributions, and dictionaries/sets) Lazy Dictionaries A [Software Transactional Memory](https://en.wikipedia.org/wiki/Software_transactional_memory) system An asynchronous Actor type, based on [Clojure’s agents](https://clojure.org/reference/agents) A Volatile type that…

I can’t recommend Hickey’s talk highly enough on what’s wrong with almost all “information” systems (regarding what he calls place-oriented programming, which implies imperative, almost a synonym, it seems imperative is maybe more general, on how to implement the former).

> **[Keynote: The Value of Values](https://www.infoq.com/presentations/Value-Values/)**
>
> Rich Hickey compares value-oriented programming with place-oriented programming concluding that the time of imperative languages has passed and it is the time of functional programming.

If it seems long, or you only have a limited amount of time, I recommend giving it a change for even just the first 3-18 min. to see if it’s of interest.

I watched this talk recently, and then immediately again it’s that good, I would say required for all programmers. Note, do not watch it full-screen. I missed out on the slides the first time. That was only part of the reason to watch again, to check if I missed something there. I wouldn’t say it was needed, it was all very clear.

Julia immutable be default in lots of ways, strings, structs, but not arrays/containers, e.g. `Dict`s. but Air.jl fixes that for all (included in the standard library, in both missing mainly ordered `Dict`s), the important data structures and arrays

> [@whatsthecraic](#):
>
> in C++ `class Foo { int x; cont int y; };` ?

You have a typo cont-\>const, consider editing your post and doing this way:

```julia
julia> mutable struct Foo
           x::Int
           __y::Int
       end

```

Then x is mutable, more like in C++, while actually \_\_y too (but \_\_ prefix means stay away), i.e. the whole `struct`. Yes, that’s place-oriented-programming (PLOP)… what you aim for is only half that, a half-sin, and I’m not really sure it’s better. So also consider fully immutable, the default, that you can still use with arrays, but then again you’re back to PLOP. `PArray` would fix that.

---

_[View the full topic](https://discourse.julialang.org/t/partially-mutable-object/70463)._