# MethodError for same type after includes / modules

**URL:** <https://discourse.julialang.org/t/methoderror-for-same-type-after-includes-modules/118771>\
**Category:** General Usage\
**Tags:** question\
**Created:** [August 29, 2024, 2:08pm UTC](https://discourse.julialang.org/t/methoderror-for-same-type-after-includes-modules/118771 "2024-08-29T14:08:46Z")\
**Posts on this page:** 11\
**Page:** 1

<div class="post-metadata">

**Author:** ![lcm](https://avatars.discourse-cdn.com/v4/letter/l/58956e/32.png) [@lcm](https://discourse.julialang.org/u/lcm)\
**Post date:** [August 29, 2024, 2:08pm UTC](https://discourse.julialang.org/t/methoderror-for-same-type-after-includes-modules/118771/1 "2024-08-29T14:08:46Z")

</div>

If you define a type / struct in one file (here `typetest_types.jl`):

```julia
module Types
struct TestType end
end

```

and then use it in a separate file in different modules, both including `typetest_types.jl`, then one module can not run methods defined on the same type in the other module:

```julia
module A
include("typetest_types.jl")
using .Types: TestType

f(x::TestType) = println("☼")
end

module Test
include("typetest_types.jl")
using .Types: TestType

using ..A: f

function test()
    f(TestType())
end
end

```

As evidenced by attempting to run `Test.test()`:

```julia
ERROR: MethodError: no method matching f(::Main.Test.Types.TestType)

Closest candidates are:
  f(::Main.A.Types.TestType)

```

Why are `A.Types.TestType` and `Test.Types.TestType` not recognized as the same type?  
I know that this can be fixed by importing `TestType` from `A` instead of from `Types`, but are qualified names always distinct even if they point the the same thing?

Additionally (I didn’t test this), doesn’t this lead to a problem similar to the Diamond Problem in OO?

---

<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:** [August 29, 2024, 2:28pm UTC](https://discourse.julialang.org/t/methoderror-for-same-type-after-includes-modules/118771/2 "2024-08-29T14:28:15Z")

</div>

> [@lcm](#):
>
> Why are `A.Types.TestType` and `Test.Types.TestType` not recognized as the same type?

You `include` the file defining the type twice, so you end up with two different types in different namespaces that have the same name.

Do `using ..A.Types: TestType` in `Testing` instead and the types will be the same.

---

<div class="post-metadata">

**Author:** ![lcm](https://avatars.discourse-cdn.com/v4/letter/l/58956e/32.png) [@lcm](https://discourse.julialang.org/u/lcm)\
**Post date:** [August 30, 2024, 8:36am UTC](https://discourse.julialang.org/t/methoderror-for-same-type-after-includes-modules/118771/3 "2024-08-30T08:36:52Z")

</div>

That’s because in my real use case, modules `A` and `Test` are in different files as well. So I’d have to include the file of `A` only.

However, this breaks when `A` is not the only module defining functions for `TestType`. Suppose there is another file `typetest_B.jl`:

```julia
module B
include("typetest_types.jl")
using .Types: TestType

f(x::TestType) = println("B")
end

```

And the module `Test` changes to:

```julia
module Test
include("typetest_B.jl")

using ..A
using .B

function test()
    A.f(A.TestType())
    B.f(A.TestType())
end
end

```

Then `A.f` executes but `B.f` fails with the same `MethodError`. Calling `B.f(B.TestType())` works, but having to manually keep track of which method takes which name seems weird, especially when not using the qualified name for the function call (as opposed to this example here). How do big packages mange their type definitions and internal `import`s/`include`s? Is every `module` just published as its own separate package?

---

<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:** [August 30, 2024, 8:45am UTC](https://discourse.julialang.org/t/methoderror-for-same-type-after-includes-modules/118771/4 "2024-08-30T08:45:29Z")

</div>

Don’t `include` a file more than once. Files and modules are not linked to each other; if you include a file twice, you define a _new, distinct_ version of whatever is in the included file. It’s similar to how you don’t `#include` the same header file twice in C or C++.

> [@lcm](#):
>
> How do big packages mange their type definitions and internal `import`s/`include`s?

Most packages I know of that split their architecture into multiple files with submodules have one `include` per file in their top level module, and use the dedicated namespace traversal syntax (like `using ...A.B: foo`) to access their types.

---

<div class="post-metadata">

**Author:** ![lcm](https://avatars.discourse-cdn.com/v4/letter/l/58956e/32.png) [@lcm](https://discourse.julialang.org/u/lcm)\
**Post date:** [August 30, 2024, 8:54am UTC](https://discourse.julialang.org/t/methoderror-for-same-type-after-includes-modules/118771/5 "2024-08-30T08:54:57Z")

</div>

> [@Sukera](#):
>
> Don’t `include` a file more than once. Files and modules are not linked to each other; if you include a file twice, you define a _new, distinct_ version of whatever is in the included file

Thank you, didn’t know that 😀

> [@Sukera](#):
>
> one `include` per file in their top level module

If I understand correctly this would be hard to adopt for a collection of loosely related files, where different tasks depend on the same types, as everything would have to be imported every single time. For example, one module might be responsible for reading data from a file and parsing it to a custom type, then analyzing that by using big packages for nonlinear fits. Another module might use the same type but capture new data and then save it to file using binary file packages. Both need access to the underlying type and use common functionality defined in a third module, but I wouldn’t wanna run all `using` statements for every package in the project just to do a small task on some shared type. Any advice for a use case like this?

---

<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:** [August 30, 2024, 2:23pm UTC](https://discourse.julialang.org/t/methoderror-for-same-type-after-includes-modules/118771/6 "2024-08-30T14:23:16Z")

</div>

You don’t need to run every `using` of your entire codebase in every module, just what you need for that module. Avoid deeply nested/convoluted module hierarchies; you don’t need one module in each source file.

If the code is all related to working with that one type, why split it up into multiple modules? If it’s all operating on the same types, the code doesn’t really sound “loosely related” to me.

---

<div class="post-metadata">

**Author:** ![lcm](https://avatars.discourse-cdn.com/v4/letter/l/58956e/32.png) [@lcm](https://discourse.julialang.org/u/lcm)\
**Post date:** [September 2, 2024, 12:19pm UTC](https://discourse.julialang.org/t/methoderror-for-same-type-after-includes-modules/118771/7 "2024-09-02T12:19:41Z")

</div>

> [@Sukera](#):
>
> You don’t need to run every `using` of your entire codebase in every module

That’s what happens if you have one central file `include`ing every other one though, right? Isn’t that what you indicated big packages do?  
The parent/sister module referencing is nice, but is there a way do conditionally `include` a file, like a C include guard?

> [@Sukera](#):
>
> If the code is all related to working with that one type, why split it up into multiple modules?

Because I have several types representing different data with a module each for analyzing that one type, but then have different modules that combine several or all types for compound analysis.  
In one compound analyis I wanted to use functions from the specialised `module`s as well, that’s how I ended up with `MethodError` and started this post.

---

<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:** [September 3, 2024, 6:00am UTC](https://discourse.julialang.org/t/methoderror-for-same-type-after-includes-modules/118771/8 "2024-09-03T06:00:38Z")

</div>

> [@lcm](#):
>
> That’s what happens if you have one central file `include`ing every other one though, right?

What I mean is that you don’t need a `using Foo` or similar if the module that’s written in doesn’t actually need anything from `Foo`. You of course still need that for stuff you actually need in that module.

> [@lcm](#):
>
> Isn’t that what you indicated big packages do?

Only for the things they actually need there. I’m also saying that I’ve not seen a codebase split up in the way you describe. What advantage does doing this offer you as a developer?

> [@lcm](#):
>
> The parent/sister module referencing is nice, but is there a way do conditionally `include` a file, like a C include guard?

No, I don’t think so. I guess you could emulate that by wrapping your entire file with an `if` that checks for definedness if the module, but that doesn’t actually solve your problem once you have slightly deeper module hierarchies. Again, modules are an explicit namespacing mechanism the languages provides for you to solve this exact problem.

> [@lcm](#):
>
> Because I have several types representing different data with a module each for analyzing that one type, but then have different modules that combine several or all types for compound analysis.

To me that sounds like you’re using too many modules with a very narrow focus. It’s admittedly a bit difficult to give specific advise without having code at hand, but I currently don’t follow what advantage you get out of that level of namespacing.

---

<div class="post-metadata">

**Author:** ![lcm](https://avatars.discourse-cdn.com/v4/letter/l/58956e/32.png) [@lcm](https://discourse.julialang.org/u/lcm)\
**Post date:** [September 3, 2024, 2:31pm UTC](https://discourse.julialang.org/t/methoderror-for-same-type-after-includes-modules/118771/9 "2024-09-03T14:31:34Z")

</div>

Okay, I guess that’s a lesson learned for my next research project. I mainly introduced all the modules so I could reuse function names around different files.

However, getting rid of the modules leads to redefinition when doubly `include`ing files, right? So instead of the original `MethodError`, you would see a bunch of the “conflicts with existing identifier” warnings. At least thing would run then…

---

<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:** [September 3, 2024, 3:30pm UTC](https://discourse.julialang.org/t/methoderror-for-same-type-after-includes-modules/118771/10 "2024-09-03T15:30:06Z")

</div>

> [@lcm](#):
>
> However, getting rid of the modules leads to redefinition when doubly `include`ing files, right?

Again, you don’t need to doubly-include anything. `include`ing a file C-style is not the same as namespacing/giving access to the same name. If you have file A, B and C and you include B and C in A, both B and C will see each others definitions. If B and C contain modules, you can traverse the namespace with e.g `using` to get at those definitions, no additional `include` required.

That’s what I mean when I say “only place `include` at the top level module/file”, which in this example is file A.

---

<div class="post-metadata">

**Author:** ![lcm](https://avatars.discourse-cdn.com/v4/letter/l/58956e/32.png) [@lcm](https://discourse.julialang.org/u/lcm)\
**Post date:** [September 4, 2024, 8:17am UTC](https://discourse.julialang.org/t/methoderror-for-same-type-after-includes-modules/118771/11 "2024-09-04T08:17:09Z")

</div>

Thank you!