# "Locally global" variable?

**URL:** <https://discourse.julialang.org/t/locally-global-variable/60471>\
**Category:** General Usage\
**Tags:** scope\
**Created:** [May 3, 2021, 4:49pm UTC](https://discourse.julialang.org/t/locally-global-variable/60471 "2021-05-03T16:49:50Z")\
**Posts on this page:** 1\
**Showing post:** 19

<div class="post-metadata">

**Author:** ![BambOoxX](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/bambooxx/32/22179_2.png) [@BambOoxX](https://discourse.julialang.org/u/BambOoxX)\
**Post date:** [May 4, 2021, 5:35pm UTC](https://discourse.julialang.org/t/locally-global-variable/60471/19 "2021-05-04T17:35:44Z")

</div>

So just to sum up a bit

- Messaging should only take / return one argument (if server is omitted) : the byte package / the data passed
- Filtering conditions based on `data` may be performed inside or outside of `computeSomething` as convenience.
- Variables that should be accessible in the main loop should be so through an appropriate container. For instance

```julia
mutable struct MyOverallContainer
    data1::Data1
    data2::Data2
    result1::Result1
end

```

Which would then be passed and modified by each `computeSomething` call.  
By the way I think this would not work for me because all of my structures are actually immutables so I wouldn’t know how to initialize this starting `MyOverallContainer`, but a `Dict` would surely work.

Do you agree with this summary ?

> [@Jeff\_Emanuel](#):
>
> In short, break the problem into smaller distinct parts and solve those separately. You’ll discover that your problems and solutions will be reusable. Resist temptation to throw it all in a big pile because the pile will become unwieldy fast.

Yeah, that was my plan, but I just came up with this code like few hours of work ago, so understanding was the priority.

---

_[View the full topic](https://discourse.julialang.org/t/locally-global-variable/60471)._