# 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:** 5
**Page:** 2
### Author:  [@Niall](https://discourse.julialang.org/u/Niall)
#### Post date: [January 7, 2017, 8:16am UTC](https://discourse.julialang.org/t/private-states-in-julia-modules/1312/21 "2017-01-07T08:16:58Z")
In the day I’ve been away, it seems the discussion has taken a different turn. That’s fine, but I want to state my position clearly:
1. While sympathising with @ScottPJones’s concerns, my issue is not with modules/namespaces: they constitute a permissive structure which _might_ get a bit clunky for the rollercoasting world of Julia if privacy were introduced.
2. I am never for lint solutions. While not necessarily laying down rules for responsible adult behaviour, a computer language should define what the term ‘responsible adult’ means. Sane laws do not permit children to walk around carrying guns, but instead provide them with a social context in which that isn’t necessary. IMO Julia needs to provide a clear definition of forms of behaviour which are known to be dangerous and provide a minimal opportunity for programmers to prohibit that behaviour.
3. Tampering with certain data fields in a type can be (a) dangerous and (b) non-obvious. I teach programming to students and they do not always document their programs to indicate that this field fulfills a constraint which must not be violated. Julia should provide a simple, minimal way for the programmer to do this, which if later removed will not bring all clients crashing to the ground. The solution must therefore be prohibitive, rather than permissive.
4. In my opinion, a simple, minimally prohibitive way of doing this is to allow the keyword ‘private’ to label sections of _type-datafields_ _only_ (so no functions or constructors) as being visible only to the next enclosing scope. This would give all multiply dispatched functions in the enclosing module the opportunity to have their wicked way with the private fields, and if the word ‘private’ were later removed, no-one would get burned.
---
### Author:  [@lobingera](https://discourse.julialang.org/u/lobingera)
#### Post date: [January 7, 2017, 8:48am UTC](https://discourse.julialang.org/t/private-states-in-julia-modules/1312/22 "2017-01-07T08:48:54Z")
> [@Niall](#):
>
> a simple, minimally prohibitive way of doing this is to allow the keyword ‘private’ to label sections of type-datafields only (so no functions or constructors) as being visible only to the next enclosing scope.
And how is your plan to implement that?
---
### Author:  [@Niall](https://discourse.julialang.org/u/Niall)
#### Post date: [January 8, 2017, 7:07am UTC](https://discourse.julialang.org/t/private-states-in-julia-modules/1312/23 "2017-01-08T07:07:35Z")
I’m sorry, I don’t understand the question. Do you mean “How would I implement the compiler feature?”, or “How would I denote privacy in my code?”? In the first case, I really couldn’t say, not having looked at the compiler code - I can’t imagine it would be difficult. In the second case, I’m simply thinking of something like this:
```julia
module Wallets
type Wallet
colour::Colour;
zipFastener::Bool;
private:
contents::Float64;
maxCapacity::Float64;
end
end
```
(Sorry: I couldn’t work out how to enter tabs in this editor)
---
### Author:  [@essenciary](https://discourse.julialang.org/u/essenciary)
#### Post date: [June 11, 2019, 5:37pm UTC](https://discourse.julialang.org/t/private-states-in-julia-modules/1312/24 "2019-06-11T17:37:37Z")
I know it’s an old thread but I hope I can add a bit of value by throwing 2 extra cents - especially as I’m happy to see that this has been tagged for v2.0 (hopefully will make it through!). Although technically my interest is in private struct fields.
I stumbled onto this as part of my research into some presentation about data structures in Julia - thinking how to memoize the length of a linked list so that `length(l::LinkedList)` would run at O(1) instead of O(n). Obviously, by having a `length` field which is kept in sync with the actual number of nodes. But I was wondering how to keep that private so it can’t be tampered with. I thought a good idea would be to peek into Julia’s `Dict` type and see how it’s done there. Unfortunately, that didn’t help as one can just change the `count` field messing it all up:
```julia
julia> length(d)
3
julia> d.count = 30
30
julia> length(d)
30
```
* * *
My point is: most replies assume that code will always run in a fully controlled environment and that conventions will be followed. However, if due to some bug (bad stuff sometimes happens!) an attacker would be able to change the internal state of such a `Dict` and there would be logic depending on `length(d::Dict)`, it would be a nightmare to debug.
Considerate developers do not use undocumented APIs and I doubt many Julia developers are aware of the internals of a `Dict` (or other data structures) so the thought of checking the internal state would probably never occur. Because we try to abide by some informal principles of encapsulation doesn’t mean others will too - the more the language can protect us, the better.
P.S. Loving `PrivateRyan.jl` btw, too bad it hasn’t been kept up to date.
---
### Author:  [@garazha-ilya](https://discourse.julialang.org/u/garazha-ilya)
#### Post date: [November 20, 2024, 2:03pm UTC](https://discourse.julialang.org/t/private-states-in-julia-modules/1312/25 "2024-11-20T14:03:57Z")
I want to note that there has been an update regarding this question. Julia 1.11 now has the [public](https://www.julialang.org/blog/2024/10/julia-1.11-highlights/#new_public_keyword) keyword.
[Previous page](https://discourse.julialang.org/t/private-states-in-julia-modules/1312.md?page=1)