# Developing a package: hacking the include order of files
**URL:** https://discourse.julialang.org/t/developing-a-package-hacking-the-include-order-of-files/14778
**Category:** General Usage
**Created:** [September 10, 2018, 6:31pm UTC](https://discourse.julialang.org/t/developing-a-package-hacking-the-include-order-of-files/14778 "2018-09-10T18:31:20Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@DominiqueMakowski](https://discourse.julialang.org/u/DominiqueMakowski)
#### Post date: [September 10, 2018, 6:31pm UTC](https://discourse.julialang.org/t/developing-a-package-hacking-the-include-order-of-files/14778/1 "2018-09-10T18:31:20Z")
I am developing a package, let’s say `Package.jl`. In its `scr` directory, I have three files: `A.jl` and `B.jl` in which are defined three functions (`a()`, `b()` and `c()`), and the main `Package.jl` file.
The latter includes:
```julia
module Psycho
export
a, c # b is not exported
include("A.jl")
include("B.jl")
end
```
In summary, three functions (a, b, c) located in two files (A and B). Critically, both `c()` and `a()` use `b()`, which is unexported, and `c()` also uses `b()`:
a → b
c → a & b
Here’s the twist. I would like `c()` and `b()` to be in the `B.jl` file, and `a()` to be in the `A.jl` file.
It seems that the above implementation doesn’t work (it errors and says that `b()` is not defined). It works if I place `b()` in `A.jl` before the definition of `a()`, but I would like to know what are my options to avoid that? I hope the example is clear enough.
---
### Author:  [@zhangxiubo](https://discourse.julialang.org/u/zhangxiubo)
#### Post date: [September 10, 2018, 8:12pm UTC](https://discourse.julialang.org/t/developing-a-package-hacking-the-include-order-of-files/14778/2 "2018-09-10T20:12:52Z")
Is including `B.jl` before `A.jl` an option?
---
### Author:  [@simonbyrne](https://discourse.julialang.org/u/simonbyrne)
#### Post date: [September 10, 2018, 8:19pm UTC](https://discourse.julialang.org/t/developing-a-package-hacking-the-include-order-of-files/14778/3 "2018-09-10T20:19:59Z")
That should work. Are you sure you’re not actually calling `b()` before it’s defined?
---
### Author:  [@DominiqueMakowski](https://discourse.julialang.org/u/DominiqueMakowski)
#### Post date: [September 10, 2018, 8:28pm UTC](https://discourse.julialang.org/t/developing-a-package-hacking-the-include-order-of-files/14778/4 "2018-09-10T20:28:49Z")
> [@zhangxiubo](#):
>
> Is including `B.jl` before `A.jl` an option?
Sorry I got confused in my own example (I thought it’d be simpler but no 🤯), I forgot to mention that `c()` also uses `a()` and `b()`, so including B before A doesn’t work as `a()` is not defined yet… I’ll edit the question
---
### Author:  [@dfdx](https://discourse.julialang.org/u/dfdx)
#### Post date: [September 10, 2018, 8:35pm UTC](https://discourse.julialang.org/t/developing-a-package-hacking-the-include-order-of-files/14778/5 "2018-09-10T20:35:45Z")
Are you sure `a()`, `b()` and `c()` are plain functions and not type definitions? You shouldn’t have any issues with functions since they are only resolved during first call which normally happens much later than the whole module is defined.
If these are indeed functions, could you please example content of `A.jl` and `B.jl` and other steps to reproduce it (e.g. ran from REPL, used precompilation, ran as script, etc.)?
---
### Author:  [@simonbyrne](https://discourse.julialang.org/u/simonbyrne)
#### Post date: [September 10, 2018, 9:07pm UTC](https://discourse.julialang.org/t/developing-a-package-hacking-the-include-order-of-files/14778/6 "2018-09-10T21:07:11Z")
The following works:
Psycho.jl:
```julia
module Psycho
export
a, c # b is not exported
include("A.jl")
include("B.jl")
end
```
A.jl:
```julia
a() = b() + 1
```
B.jl:
```julia
b() = rand()
c() = a() + b()
```
---
### Author:  [@DominiqueMakowski](https://discourse.julialang.org/u/DominiqueMakowski)
#### Post date: [September 11, 2018, 9:17am UTC](https://discourse.julialang.org/t/developing-a-package-hacking-the-include-order-of-files/14778/7 "2018-09-11T09:17:05Z")
Yes you’re right! I simplified the code and indeed it works, sorry for this false alarm and thanks a lot 😄
---
### Author:  [@zhangxiubo](https://discourse.julialang.org/u/zhangxiubo)
#### Post date: [September 11, 2018, 6:36pm UTC](https://discourse.julialang.org/t/developing-a-package-hacking-the-include-order-of-files/14778/8 "2018-09-11T18:36:26Z")
Just a follow up question — how about interdependent types? e.g.
A.jl:
```julia
struct A
b :: B
end
```
B.jl:
```julia
struct B
a :: A
end
```
It seems in this case the runtime will complain about type `B` being undefined when A.jl is included.
For interpreted languages, this behaviour is understandable; but I still wonder how one should declare/organise interdependent types?
---
### Author:  [@dfdx](https://discourse.julialang.org/u/dfdx)
#### Post date: [September 11, 2018, 6:53pm UTC](https://discourse.julialang.org/t/developing-a-package-hacking-the-include-order-of-files/14778/9 "2018-09-11T18:53:25Z")
Not quite optimal, but works in practice:
A.jl:
```julia
abstract type AbstractB end
struct A
b::AbstractB
end
```
B.jl
```julia
struct B <: AbstractB
a::A
end
```
---
### Author:  [@zhangxiubo](https://discourse.julialang.org/u/zhangxiubo)
#### Post date: [September 11, 2018, 11:02pm UTC](https://discourse.julialang.org/t/developing-a-package-hacking-the-include-order-of-files/14778/10 "2018-09-11T23:02:04Z")
Thanks for the example, though I agree that this setup is less ideal.
In my original example, I do wonder why Julia runtime needs to complain about not knowing type `B` during pre-compilation time — wouldn’t it be possible for Julia runtime to parse all the type definitions at once like other AOT-compiled languages?
---
### Author:  [@simonbyrne](https://discourse.julialang.org/u/simonbyrne)
#### Post date: [September 11, 2018, 11:06pm UTC](https://discourse.julialang.org/t/developing-a-package-hacking-the-include-order-of-files/14778/11 "2018-09-11T23:06:39Z")
Parametric types can also be used, and avoid the performance problems of abstract types as fields.
Anyway, this is a long-standing issue: [handle mutually-circular type declarations · Issue #269 · JuliaLang/julia · GitHub](https://github.com/JuliaLang/julia/issues/269)