# Exportall might be useful in some (limited) cases?

**URL:** <https://discourse.julialang.org/t/exportall-might-be-useful-in-some-limited-cases/80872>\
**Category:** Internals & Design\
**Created:** [May 11, 2022, 9:43am UTC](https://discourse.julialang.org/t/exportall-might-be-useful-in-some-limited-cases/80872 "2022-05-11T09:43:59Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![jsjie](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jsjie/32/22477_2.png) [@jsjie](https://discourse.julialang.org/u/jsjie)\
**Post date:** [May 11, 2022, 9:43am UTC](https://discourse.julialang.org/t/exportall-might-be-useful-in-some-limited-cases/80872/1 "2022-05-11T09:43:59Z")

</div>

There are many good points against common use of exportall:

1. possible name conflicts when importing from different packages
2. with explicit export, we know what symbols are intended for internal uses only, and what are intended for external uses

However, these arguments might not be suitable for some specific cases.

I’m wring a somewhat large package for DFT, and I organize my code into submodules.  
Since every submodule has its own namespace, import/export/using becomes something to be considered.

I’ve met two things for which exportall might be useful:

1. Physical constants.
2. type aliases.

Currently, I have a submodule called `PhysicalConstants`, and I’m left with three choices:

1. manually export everything in `PhysicalConstants`
2. manually import everything I use in every submodule that uses `PhysicalConstants` - nearly every submodule else
3. `using PhysicalConstants`, then in my code, write something like `PhysicalConstants.eV * PhysicalConstants.angstrom` over and over and over again, or, somewhat better, a `using PhisicalConstants as m` then `m.eV * m.angstrom` - but let’s consider readability, a magic name like `m` is definitely mysterious, and any reasonble name, like `consts` or so, are somewhat long.

In my opinion, for this specific case, exportall functionality is quite handy and should not introduce any problems.  
The main argument here is, physical constants should be somewhat unique, so they should not get involved into name conflicts. It will be ridiculous that you ever need two different `planck_constant`s , if not for different unit systems.  
However, we are now talking about import inside one package, between different submodules.  
Inside a package, it is rational to keep to one unit system, and perform unit transform only in specific I/O functions. So there should only be one value for a physical constant, and there should not be any name conflicts.

* * *

ps: Off topic, but global variables are also commonly regard as bad, and many tend to declare “no global variables” in every post they met. However, for something like physical constants - which might be defined as macro in C - are there better, simple way to do this?

---

<div class="post-metadata">

**Author:** ![jacobusmmsmit](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jacobusmmsmit/32/217669_2.png) [@jacobusmmsmit](https://discourse.julialang.org/u/jacobusmmsmit)\
**Post date:** [May 11, 2022, 10:48am UTC](https://discourse.julialang.org/t/exportall-might-be-useful-in-some-limited-cases/80872/2 "2022-05-11T10:48:55Z")

</div>

> [@jsjie](#):
>
> However, for something like physical constants - which might be defined as macro in C - are there better, simple way to do this?

You can write

```julia
const h = 6.62607015e−34

```

and you don’t have to worry about it being global anymore as the compiler can infer its type (as it can’t change).

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [May 11, 2022, 11:04am UTC](https://discourse.julialang.org/t/exportall-might-be-useful-in-some-limited-cases/80872/3 "2022-05-11T11:04:11Z")

</div>

> [@jsjie](#):
>
> Currently, I have a submodule called `PhysicalConstants` , and I’m left with three choices:

Shameless self-plug: did you see [`PhysicalConstants.jl`](https://github.com/JuliaPhysics/PhysicalConstants.jl)?

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [May 11, 2022, 11:06am UTC](https://discourse.julialang.org/t/exportall-might-be-useful-in-some-limited-cases/80872/4 "2022-05-11T11:06:40Z")

</div>

> [@jsjie](#):
>
> global variables are also commonly regard as bad

To be clear, _ **non-constant** _ globals are commonly regarded as bad. Constant globals are perfectly fine: [Performance Tips · The Julia Language](https://docs.julialang.org/en/v1/manual/performance-tips/#Avoid-global-variables)

---

<div class="post-metadata">

**Author:** ![jsjie](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jsjie/32/22477_2.png) [@jsjie](https://discourse.julialang.org/u/jsjie)\
**Post date:** [May 13, 2022, 3:09am UTC](https://discourse.julialang.org/t/exportall-might-be-useful-in-some-limited-cases/80872/5 "2022-05-13T03:09:16Z")

</div>

Yes, I checked it when I began my project, and found it had rich features like different codata versions, uncertainty data and so on, which seemed to be an overkill, so I didn’t use it then.  
But I’m considering to turn to it now.

* * *

Back to the main topic, I checked your repo and found constants are defined with macro constant and derived\_constant. It seems that export is done in `_constant_begin`. It is somehow similar to the first proposed way, i.e., manually export everything?

---

<div class="post-metadata">

**Author:** ![jsjie](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jsjie/32/22477_2.png) [@jsjie](https://discourse.julialang.org/u/jsjie)\
**Post date:** [May 13, 2022, 3:12am UTC](https://discourse.julialang.org/t/exportall-might-be-useful-in-some-limited-cases/80872/6 "2022-05-13T03:12:03Z")

</div>

Someone definitely have different ideas, can see [this post](https://discourse.julialang.org/t/best-practice-for-array-allocation-in-self-consistent-calculations/79371/9)

---

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [May 13, 2022, 5:12am UTC](https://discourse.julialang.org/t/exportall-might-be-useful-in-some-limited-cases/80872/7 "2022-05-13T05:12:45Z")

</div>

To be clear here, what I was referring to was constantly reading & writing those globals. The compiler can’t make that more efficient, even if it could in some circumstances when the variable would not be a global, because it should ensure that the value is actually being written to the global. This can remove a lot of optimizations using that variable. I’m not sure it always does, but that’s the mental model I’ve always been going with and which served me well so far. Reading/writing once isn’t that bad and unlikely to be performance critical anyway.

---

<div class="post-metadata">

**Author:** ![jsjie](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/jsjie/32/22477_2.png) [@jsjie](https://discourse.julialang.org/u/jsjie)\
**Post date:** [May 16, 2022, 1:09am UTC](https://discourse.julialang.org/t/exportall-might-be-useful-in-some-limited-cases/80872/8 "2022-05-16T01:09:39Z")

</div>

In my opinion, what matters more is not whether the variable is read/written once or constantly, but whether it is read-only, or can be changed. Physical constans, as discussed here, should be read-only, but may be read frequently.  
I think that the compiler can do much to optimize read-only variables, but in Julia, it seems that we cannot inform compiler about this?  
Mutable objects, whose reference are read-only, are harder to analyze and I don’t quite know.

Anyway, my main point is that global variables may sometimes be appropriate to use. Whether they have performance impact is a technical problem that is important in some cases and not important in others. Rejecting them anywhere without any thought is not wise.

---

<div class="post-metadata">

**Author:** ![odow](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/odow/32/28685_2.png) [@odow](https://discourse.julialang.org/u/odow)\
**Post date:** [May 16, 2022, 2:38am UTC](https://discourse.julialang.org/t/exportall-might-be-useful-in-some-limited-cases/80872/9 "2022-05-16T02:38:57Z")

</div>

You can export all symbols (or a subset) as follows:

> <https://github.com/jump-dev/JuMP.jl/blob/f233dd11677b8164c509ebf4a1be16971933b4cf/src/JuMP.jl#L1379-L1402>

---

<div class="post-metadata">

**Author:** ![Sukera](https://avatars.discourse-cdn.com/v4/letter/s/ce7236/32.png) [@Sukera](https://discourse.julialang.org/u/Sukera)\
**Post date:** [May 16, 2022, 8:18am UTC](https://discourse.julialang.org/t/exportall-might-be-useful-in-some-limited-cases/80872/10 "2022-05-16T08:18:52Z")

</div>

> [@jsjie](#):
>
> Physical constans, as discussed here, should be read-only, but may be read frequently.  
> I think that the compiler can do much to optimize read-only variables, but in Julia, it seems that we cannot inform compiler about this?

There is `const` for these and for immutable constants it’s absolutely fine to use them if you only ever read from them (they’ll be inlined in those cases). However, if the possibility of writing to them exists, the compiler may not always inline (with a drop in performance, due to having to look them up all the time). It’s a tradeoff that most of the time favors the “don’t be global” side, since people often want to write to them as well.