# Should abstract types be exported?

**URL:** <https://discourse.julialang.org/t/should-abstract-types-be-exported/52359>\
**Category:** General Usage\
**Tags:** question, type\
**Created:** [December 25, 2020, 3:04am UTC](https://discourse.julialang.org/t/should-abstract-types-be-exported/52359 "2020-12-25T03:04:17Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![mkarikom](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mkarikom/32/7096_2.png) [@mkarikom](https://discourse.julialang.org/u/mkarikom)\
**Post date:** [December 25, 2020, 3:04am UTC](https://discourse.julialang.org/t/should-abstract-types-be-exported/52359/1 "2020-12-25T03:04:17Z")

</div>

My module has a few composite types like: `struct myType1 <: ModFooAbstractType`.  
It seems the intent of abstract types is that they are an interface for functions, not necessarily defined in the same module, like:

```julia
using ModFoo

function bar(x::ModFooAbstractType)
   print("bar")
end

```

Are there any drawbacks to this?

---

<div class="post-metadata">

**Author:** ![Henrique\_Becker](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/henrique_becker/32/15443_2.png) [@Henrique\_Becker](https://discourse.julialang.org/u/Henrique_Becker)\
**Post date:** [December 25, 2020, 4:24am UTC](https://discourse.julialang.org/t/should-abstract-types-be-exported/52359/2 "2020-12-25T04:24:03Z")

</div>

Someone could explain better but:

1. You can create new methods for functions in other module.
2. You can create your own functions using concrete types of other modules.

Consequently, it seems to me that exporting `abstract` structs is only useful if:

1. It is clear which are the functions that any new subtypes of your exported abstract types should implement.
2. You wanna allow for the users to both:
  1. Create new subtypes of your abstract types that will work automatically with any generic/fallback functions you have written.
  2. Allow them to write generic/fallback functions for your abstract types, i.e., they can write functions that can be extended for specific concrete types, but already have a generic implementation that should work for any subtype of your abstract type anyway.

---

<div class="post-metadata">

**Author:** ![MA\_Laforge](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ma_laforge/32/385_2.png) [@MA\_Laforge](https://discourse.julialang.org/u/MA_Laforge)\
**Post date:** [December 26, 2020, 8:46pm UTC](https://discourse.julialang.org/t/should-abstract-types-be-exported/52359/3 "2020-12-26T20:46:38Z")

</div>

> [@mkarikom](#):
>
> Are there any drawbacks to this?

Not at all. This is what Julia was designed to do. It was meant to be extensible in this way.

I don’t disagree with @Henrique_Becker, but [your] response makes it sound like this pattern is to be avoided in all but a few restricted cases.

I think this feature is very powerful and might actually be useful (and more elegant) to solve more problems than most of us currently associate with this technique.

EDIT: There may indeed be drawbacks, but I don’t see any in your particular example.

---

<div class="post-metadata">

**Author:** ![MA\_Laforge](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ma_laforge/32/385_2.png) [@MA\_Laforge](https://discourse.julialang.org/u/MA_Laforge)\
**Post date:** [December 26, 2020, 8:58pm UTC](https://discourse.julialang.org/t/should-abstract-types-be-exported/52359/4 "2020-12-26T20:58:03Z")

</div>

### Meaning of export

As a sidenote: In Julia, the term “exported” means your `ModFoo` module runs:

```julia-auto
export ModFooAbstractType

```

Which makes the symbol `ModFooAbstractType` directly available to any module that calls `using ModFoo`.

### Should you `export`?

So if you are asking whether it is a good idea to export this symbol, it all depends on if the convenience of having that symbol directly available to your users instead of explicitly qualifying the new type. Here is an example of using an explicit `ModFoo.` qualifier:

```julia-auto
using ModFoo

function bar(x::ModFoo.ModFooAbstractType)
   print("bar")
end

```

Note that, by not `export`-ing the symbol, you can rename `ModFooAbstractType` → `SomeAbstractType` without worrying about name collisions.

So really, your choice to export is a tradeoff between convenience for module users to write the type name without needing an explicit qualifier, and the inconvenience of potential name collisions.