# Private states in Julia modules

**URL:** https://discourse.julialang.org/t/private-states-in-julia-modules/1312
**Category:** General Usage
**Tags:** question, package
**Created:** [January 5, 2017, 7:38pm UTC](https://discourse.julialang.org/t/private-states-in-julia-modules/1312 "2017-01-05T19:38:23Z")
**Posts on this page:** 1
**Showing post:** 17

<div class="post-metadata">

### Author: ![ScottPJones](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/scottpjones/32/146_2.png) [@ScottPJones](https://discourse.julialang.org/u/ScottPJones)
#### Post date: [January 6, 2017, 2:10pm UTC](https://discourse.julialang.org/t/private-states-in-julia-modules/1312/17 "2017-01-06T14:10:38Z")

</div>

The reverse: `export` would not change at all.

1. **export** would imply **public** , as well as (via `using`) being added to the namespace
2. **public** names would be available without any special syntax via qualification (`<module>.<name>`)
3. any other names require the `<module>..<name>` qualification (of course, you can do `const foo = SPJ..foo` to avoid paying the sin tax more than once in your module 😉 )

The last part is what helps later on, when you are trying to find all the places that might be broken due to changes in internals, and also helps people remember that they _are_ accessing something that might change in the future  
(like using functions with the `unsafe_` prefix, you know you are treading into deep waters).  
That’s why I like the concept of a “sin tax”, it doesn’t _prevent_ you from “sinning”, but you do know that you are breaking one of the (encapsulation) commandments.

---

_[View the full topic](https://discourse.julialang.org/t/private-states-in-julia-modules/1312)._
