# Is accessing the fields of a struct a good julia-style?

**URL:** <https://discourse.julialang.org/t/is-accessing-the-fields-of-a-struct-a-good-julia-style/23623>\
**Category:** General Usage\
**Created:** [April 28, 2019, 5:34pm UTC](https://discourse.julialang.org/t/is-accessing-the-fields-of-a-struct-a-good-julia-style/23623 "2019-04-28T17:34:26Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![fverdugo](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/fverdugo/32/9446_2.png) [@fverdugo](https://discourse.julialang.org/u/fverdugo)\
**Post date:** [April 28, 2019, 5:34pm UTC](https://discourse.julialang.org/t/is-accessing-the-fields-of-a-struct-a-good-julia-style/23623/1 "2019-04-28T17:34:26Z")

</div>

I need to implement a `struct` that represents a vector of vectors (a.k.a. a ragged/jagged array) in compressed form:

```julia
struct Foo{T}
  data::Vector{T}
  ptrs::Vector{Int}
end

```

where the field `data` contains the flatted values of the jagged array and `ptrs` contains the start position in the `data` vector for each of the sub-vectors. Just to clarify, the vector of vectors `v = [[1,2],[2,5,1],[7]]` would be represented as `f = Foo([1,2,2,5,1,7],[1,3,6,7])`

**My question is this one: is a good style to direct access the fields of `Foo` in the user code, namely writing `f.data` and `f.ptrs` ?**

or is it better to define the getter functions `data(f::Foo) = f.data`, and `ptrs(f::Foo) = f.ptrs` and use them instead?

The problem with the latter options is that it is likely that `data` is already defined in some package leading to name collisions. I could use longer names like `get_foo_data` but I don’t find it elegant.

Here I am missing the name space provided by classes in object oriented languages. What is the way to go in julia in this context?

Thanks for the help!

---

<div class="post-metadata">

**Author:** ![dlfivefifty](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dlfivefifty/32/1959_2.png) [@dlfivefifty](https://discourse.julialang.org/u/dlfivefifty)\
**Post date:** [April 28, 2019, 7:13pm UTC](https://discourse.julialang.org/t/is-accessing-the-fields-of-a-struct-a-good-julia-style/23623/2 "2019-04-28T19:13:19Z")

</div>

I think yes: some StdLib types have that pattern, e.g. `lu(A).L`.

Since you can override `getproperty` now it’s no longer so brittle for depreciations.

---

<div class="post-metadata">

**Author:** ![dfdx](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dfdx/32/120_2.png) [@dfdx](https://discourse.julialang.org/u/dfdx)\
**Post date:** [April 28, 2019, 7:19pm UTC](https://discourse.julialang.org/t/is-accessing-the-fields-of-a-struct-a-good-julia-style/23623/3 "2019-04-28T19:19:52Z")

</div>

Julia lets you define accessors later, e.g. if you rename the fields, you can still provide old names using `getproperty()`:

```julia
struct Foo{T}
  new_data::Vector{T}
  new_ptrs::Vector{Int}
end

function Base.getproperty(foo::Foo, p::Symbol)
    if p == :data
        return getfield(foo, :new_data) # getfield() reads fields directly and it cannot be overloaded
    elseif p == :ptrs
        return getfield(foo, :new_ptrs)
    else
        return getfield(foo, p)
    end
end

f = Foo([1,2,2,5,1,7],[1,3,6,7])
println(f.data)
println(f.ptrs)

```

Note that Julia compiler is smart enough to still translate simple `getproperty()` calls into direct field pointers:

```julia
julia> using BenchmarkTools

julia> @btime $f.data;
  1.753 ns (0 allocations: 0 bytes)

julia> @btime $f.new_data;
  1.754 ns (0 allocations: 0 bytes)

```

There’s also `Base.setproperty!()` for property mutation.

---

<div class="post-metadata">

**Author:** ![kevbonham](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kevbonham/32/216165_2.png) [@kevbonham](https://discourse.julialang.org/u/kevbonham)\
**Post date:** [April 28, 2019, 7:21pm UTC](https://discourse.julialang.org/t/is-accessing-the-fields-of-a-struct-a-good-julia-style/23623/4 "2019-04-28T19:21:22Z")

</div>

While true, I think defining functions is more idiomatic. The upside being you can alter the underlying representation without a need to change the API.

At the same time, I don’t know that defining `data()` as a function is a good idea… Seems like way too generic a name. I suppose as long as you’re sure you’re only defining it on your own types it’s ok.

---

<div class="post-metadata">

**Author:** ![ffevotte](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ffevotte/32/6587_2.png) [@ffevotte](https://discourse.julialang.org/u/ffevotte)\
**Post date:** [April 28, 2019, 7:35pm UTC](https://discourse.julialang.org/t/is-accessing-the-fields-of-a-struct-a-good-julia-style/23623/5 "2019-04-28T19:35:32Z")

</div>

There have been some discussions about this here on discourse. See, for example, [Mutable struct vs closure](https://discourse.julialang.org/t/mutable-struct-vs-closure/20233), especially the part of the discussion starting with the following post:

> [@Mutable struct vs closure](https://discourse.julialang.org/t/mutable-struct-vs-closure/20233/21):
>
> Possibly, but Julia does not offer what you call traditional encapsulation, a mechanism designed to explicitly hide state (or make it difficult to access). Instead, I try to stick to the following implicit rules: only methods of the same module should modify fields of a structure, reading fields is kind of borderline, if it is needed to done frequently, it should be done with an accessor, or documented as the recommended API. If you are really paranoid, you could redefine Base.getprop…

I’m under the impression that there is a weak consensus that defining accessor functions in the public API of your module is rather better style. But there is also a lot of code (including some parts of the standard library) which exposes internal fields in the user documentation, without it causing much trouble to anybody (and indeed, clever uses of `getproperty`/`setproperty!` make this rather future-proof as demonstrated above). So I don’t think there is (yet) a strong and universally shared opinion on this.

  

If it were me, I think I would go for accessor methods. Or even better, since the type in question is not POD, I would perhaps not worry much about accessing the internal fields of the structure (`data` and `ptrs`), and rather try to expose a meaningful API, which allows manipulating this structure in the most relevant way: maybe define `getindex`/`setindex!` methods for it to be indexable like an array, maybe in conjunction with `eachindex` in order to get a list of valid indices. Or an `iterate` method to iterate over the values in it. In short, with the correct API, maybe the client code does not need to access the `data` field (or even know it exists!)

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [April 29, 2019, 5:20am UTC](https://discourse.julialang.org/t/is-accessing-the-fields-of-a-struct-a-good-julia-style/23623/6 "2019-04-29T05:20:29Z")

</div>

Before `getproperty` & friends, I would have said that accessor functions are the cleanest, but now I think that it is OK to explore an API with property accessors (`x.something` instead of `getsomething(x)`). That said, property names live in a single namespace (equivalent to `Symbol`), so one does not need to export/import them etc. This has advantages and disadvantages, and should be taken into account in the API design.

Whatever the choice is, the key part is **documenting** the API very clearly, at least in the docstring of the type or an abstract type, so that the user should have not wonder whether property accessors are supported, or just happen to work and may break.