# How to deal with inconsistent objects due to mutation

**URL:** <https://discourse.julialang.org/t/how-to-deal-with-inconsistent-objects-due-to-mutation/77960>\
**Category:** General Usage\
**Tags:** design\
**Created:** [March 16, 2022, 11:45am UTC](https://discourse.julialang.org/t/how-to-deal-with-inconsistent-objects-due-to-mutation/77960 "2022-03-16T11:45:46Z")\
**Posts on this page:** 1\
**Showing post:** 8

<div class="post-metadata">

**Author:** ![jakobnissen](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jakobnissen/32/13477_2.png) [@jakobnissen](https://discourse.julialang.org/u/jakobnissen)\
**Post date:** [March 16, 2022, 12:02pm UTC](https://discourse.julialang.org/t/how-to-deal-with-inconsistent-objects-due-to-mutation/77960/8 "2022-03-16T12:02:04Z")

</div>

I’m not sure it’s a _problem_, really, as long as there is a social convention that the fields of a struct are private and should not be changed or relied on, unless explicitly documented.

It’s nice that users _can_ mess with internal types if they want, and is willing to bear the risk. It allows extension of other people’s types.

Relevant:

- [Style Guide · The Julia Language](https://docs.julialang.org/en/v1/manual/style-guide/#Prefer-exported-methods-over-direct-field-access)
- [Accessing type internal fields in package interfaces](https://discourse.julialang.org/t/accessing-type-internal-fields-in-package-interfaces/70263)

Edit: But yes, I agree, Julia’s approach of telling people to not mess with internal fields as opposed to _forcing_ people by actually making them inaccessible does prioritize performance (and extensibility) over safety. I think it’s nice still.

---

_[View the full topic](https://discourse.julialang.org/t/how-to-deal-with-inconsistent-objects-due-to-mutation/77960)._