# About inheritance and abstract types

**URL:** <https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801>\
**Category:** New to Julia\
**Tags:** inheritance\
**Created:** [September 9, 2017, 5:28pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801 "2017-09-09T17:28:13Z")\
**Posts on this page:** 20\
**Page:** 2

<div class="post-metadata">

**Author:** ![williamfgc](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/williamfgc/32/15445_2.png) [@williamfgc](https://discourse.julialang.org/u/williamfgc)\
**Post date:** [June 12, 2020, 11:15am UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/21 "2020-06-12T11:15:37Z")

</div>

Thanks you guys for the responses. My personal opinion of Julia is that it is great and the main benefit over Python for the kind of work I do is “static types”, the wonderful language built-in capabilities and the unified package distribution, Project.toml is a great idea. My curiosity about OO is that I’ve seen large code bases in C and Fortran essentially creating their own OO dialects as they grow in size and complexity. My 2 cents is that it would be nice to have it in the language.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 12, 2020, 11:31am UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/22 "2020-06-12T11:31:58Z")

</div>

> [@williamfgc](#):
>
> Julia can benefit from OO if we want to use it in large projects

Sorry, I don’t see the connection between OO and programming in the large. Maybe you can elaborate?

IMO what matters for large codebases is compartmentalization of functionality into smaller units that one can reason about. It is true that _some_ languages use OO (in combination with other things, like namespaces) to achieve this. Julia doesn’t, which is an intentional design choice. Multiple dispatch is more expressive than single-dispatch OO.

> [@williamfgc](#):
>
> composition, while nice, still doesn’t save from code duplication in all derived types.

A concrete example could be helpful to focus this discussion.

---

<div class="post-metadata">

**Author:** ![mauro3](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mauro3/32/292_2.png) [@mauro3](https://discourse.julialang.org/u/mauro3)\
**Post date:** [June 12, 2020, 11:48am UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/23 "2020-06-12T11:48:12Z")

</div>

My impression is that many people with an OO background seeing Julia for the first time think that the missing OO features are a show-stopper. However, I don’t think we see any such complaints from long term users. That could either mean that the OO-background-people left again or that the programming paradigm of Julia is good after all and there is nothing to complain. I’m pretty sure it is the latter.

Edit: So, my recommendation is to embrace Julia’s model (e.g. look at good packages) and see what you think instead of trying to port your OO habits to Julia.

---

<div class="post-metadata">

**Author:** ![williamfgc](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/williamfgc/32/15445_2.png) [@williamfgc](https://discourse.julialang.org/u/williamfgc)\
**Post date:** [June 12, 2020, 12:12pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/24 "2020-06-12T12:12:31Z")

</div>

> Sorry, I don’t see the connection between OO and programming in the large. Maybe you can elaborate?

No problem. I was referring to the legacy of large extensible code bases scientific data interacts with (which Julia targets). Think of VTK, OpenFoam, MFEM, MOOSE, ParaView, [Slate, the next generation of Scalapack](https://pdfs.semanticscholar.org/bfca/08451706d9ae99f0778b56a69e69a1210961.pdf), I can go on and on with this list. Their choice is to organize using OO architecture. Julia essentially implements the Fortran model that frameworks are moving away for better organization and due to the demands for new capabilities in a timely manner.

> Multiple dispatch is more expressive than single-dispatch OO.

Yes, this is why I consider them complimentary/orthogonal concepts wrt inheritance. Inheritance allows reusability that multiple dispatch doesn’t. These are just different hammers for different nails.

> A concrete example could be helpful to focus this discussion.

I provided an example in my first entry for `get_type(curve::BaseType) `, the mentioned alternatives mean that get\_type must be implemented in all derived types, while with inheritance a single function is sufficient as every derived class `is-a` (inheritance) rather than `has-a` (composition).

Personally, I’m not a OO advocate myself just curious about the Julia roadmap on the topic (programming languages are tools at the end of the day). I’ve just seen over the years how many scientific frameworks chose OO as an organizational model (list above). If this is coming to Julia, it would be an easier sell, that’s all.

Thanks, good conversation.

---

<div class="post-metadata">

**Author:** ![williamfgc](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/williamfgc/32/15445_2.png) [@williamfgc](https://discourse.julialang.org/u/williamfgc)\
**Post date:** [June 12, 2020, 12:20pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/25 "2020-06-12T12:20:49Z")

</div>

@mauro3 It’s not my “OO” habits or my “OO”-background (people can have multiple paradigm backgrounds). I’d say I’m comfortable with Julia’s paradigm (reminds me of Fortran), but I also see the value of OO which many framework do see as well. Just providing my feedback based on what I see. You’re welcome to take it or not. Julia is a relatively young language, I think feedback from community users and good relations is key to its success in the long-run.

---

<div class="post-metadata">

**Author:** ![mauro3](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/mauro3/32/292_2.png) [@mauro3](https://discourse.julialang.org/u/mauro3)\
**Post date:** [June 12, 2020, 12:35pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/26 "2020-06-12T12:35:55Z")

</div>

As much as I like Fortran (95), I think Julia is pretty far from it. I like the Julian way of writing code, much more so than OO, but I certainly took a bit of time to get used to it. Also, Julia is at v1 now, so large changes to the language are probably not going to happen.

Last, note that the examples you state above, except Slate, are all “old” (10+ years), when OO was still en-vouge. I think this has now changed quite bit. And it seems that in Julia it is much easier to write composable software than in many other languages, thanks to multiple dispatch: [JuliaCon 2019 | The Unreasonable Effectiveness of Multiple Dispatch | Stefan Karpinski - YouTube](https://www.youtube.com/watch?v=kc9HwsxE1OY)

Anyway, I think you just need to develop a few 1k locs of code to see if you like it.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 12, 2020, 12:38pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/27 "2020-06-12T12:38:43Z")

</div>

> [@williamfgc](#):
>
> Julia essentially implements the Fortran model

I am not sure I understand what “the Fortran model” is in this context.

> [@williamfgc](#):
>
> Their choice is to organize using OO architecture.

Again, I don’t understand the what the issue is. It is possible to provide idiomatic interfaces in Julia to external libraries that are organized using OO. There are many examples.

> [@williamfgc](#):
>
> the mentioned alternatives mean that get\_type must be implemented in all derived types

This is not true. Perhaps you missed @mauro3’s [answer](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/12).

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 12, 2020, 12:48pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/28 "2020-06-12T12:48:10Z")

</div>

> [@williamfgc](#):
>
> Julia is a relatively young language, I think feedback from community users and good relations is key to its success in the long-run.

Well, yes and no. While well-reasoned suggestions are always helpful, the language is pretty well-developed at this point, so it takes a lot of investment in the language to make practical changes. Just suggesting that “OO would be useful” is difficult to do anything about since changing something seemingly small about the language has a lot of ramifications.

Because of this, the bar for changes is rather high. I realize that this can be frustrating to well-meaning people who make such suggestions.

Personally I consider it unlikely that Julia will ever go in the OO direction in the style of C++ & co, and consider that the right choice.

Note that this has been discussed multiple times before, you may find those topics interesting. Also,

> **[Type-Dispatch Design: Post Object-Oriented Programming for Julia - Stochastic...](http://www.stochasticlifestyle.com/type-dispatch-design-post-object-oriented-programming-julia/)**
>
> In this post I am going to try to explain in detail the type-dispatch design which is used in Julian software architectures. It’s modeled after the design of many different packages and Julia Base, and has been discussed in parts elsewhere. This is...

---

<div class="post-metadata">

**Author:** ![williamfgc](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/williamfgc/32/15445_2.png) [@williamfgc](https://discourse.julialang.org/u/williamfgc)\
**Post date:** [June 12, 2020, 12:48pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/29 "2020-06-12T12:48:40Z")

</div>

> This is not true. Perhaps you missed @mauro3’s [answer](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/12).

You’re right. My mistake, the scalability problem arises from the fact that each subtype must have the field. With inheritance this duplication could be avoided exploiting the `is-a` relationship.

> I am not sure I understand what “the Fortran model” is in this context.

I was referring to modules, types and generic functions.

> Again, I don’t understand the what the issue is. It is possible to provide idiomatic interfaces in Julia to external libraries that are organized using OO.

No issue at all. Just providing the reasoning that OO can be more productive in particular applications as it could avoid boilerplate to mimic OO that scales up quickly. Productivity is key in different industries that would like to give Julia a shot.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 12, 2020, 12:54pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/30 "2020-06-12T12:54:05Z")

</div>

> [@williamfgc](#):
>
> Just providing the reasoning that OO can be more productive in particular applications as it could avoid boilerplate to mimic OO that scales up quickly.

I am not sure I understand why one would want to mimic OO boilerplate _at all_ in Julia. It is not idiomatic style, so of course it will be difficult. This difficulty is best avoided by programming Julia as intended.

I am wondering if you read eg

[https://docs.julialang.org/en/v1/manual/methods/#Design-Patterns-with-Parametric-Methods-1](https://docs.julialang.org/en/v1/manual/methods/#Design-Patterns-with-Parametric-Methods-1)

---

<div class="post-metadata">

**Author:** ![williamfgc](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/williamfgc/32/15445_2.png) [@williamfgc](https://discourse.julialang.org/u/williamfgc)\
**Post date:** [June 12, 2020, 12:58pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/31 "2020-06-12T12:58:00Z")

</div>

> Just suggesting that “OO would be useful” is difficult to do anything about since changing something seemingly small about the language has a lot of ramifications.

I think we are not reading each other. I wasn’t “just suggesting” I listed several frameworks in scientific computing that take advantage of OO, given that Julia wants to solve the two-language problem it could offer what those languages offer. I hope my feedback is well-reasoned.

> Because of this, the bar for changes is rather high. I realize that this can be frustrating to well-meaning people who make such suggestions.

Thanks for your words, you are absolutely correct. I think people asking for OO (or other features) are well-intentioned and it is more of a business need (for productivity) when trying to introduce Julia (which is also an investment for users) in their own environments. While I don’t find it frustrating, I think OO would add value to many people advocating for Julia’s adoption in production environments.

---

<div class="post-metadata">

**Author:** ![heliosdrm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/heliosdrm/32/3851_2.png) [@heliosdrm](https://discourse.julialang.org/u/heliosdrm)\
**Post date:** [June 12, 2020, 1:06pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/32 "2020-06-12T13:06:51Z")

</div>

> [@mauro3](#):
>
> That could either mean that the OO-background-people left again or that the programming paradigm of Julia is good after all and there is nothing to complain. I’m pretty sure it is the latter.

Good question to add in the next [Julia users and developer Survey](https://juliacomputing.com/survey/), to see if that’s one of the characteristics that users like or dislike most. (Unfortunately, it’ll be harder to measure the opinion of people who left.)

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 12, 2020, 1:13pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/33 "2020-06-12T13:13:56Z")

</div>

> [@williamfgc](#):
>
> I wasn’t “just suggesting” I listed several frameworks in scientific computing that take advantage of OO, given that Julia wants to solve the two-language problem it could offer what those languages offer. I hope my feedback is well-reasoned.

Sorry, I still don’t understand this line of reasoning. In particular,

1. A lot of frameworks indeed take advantage of OOP. It is unclear whether this happened for historical reasons (eg the software was started when OOP was considered the best solution), practical considerations (they wanted to use C++, which means buying into this kind of OOP).

2. Even if C++-style OOP is the right idiom in C++, this does not mean that it is the right choice in Julia, which is a fundamentally different language with other features that allow you to organize code equally or more efficienly, but using a different approach.

3. The “two-language problem” is having to use another language to write fast code. I don’t understand what it has to do with OOP.

> [@williamfgc](#):
>
> people asking for OO (or other features) are well-intentioned and it is more of a business need (for productivity)

To put it mildly, the link between OOP and productivity is yet to be demonstrated _across languages_. It is of course true that to be productive in an OOP-based language, you use OOP. But people have been skeptical about this since the enthusiasm about OOP peaked. This lead to the design of a lot of new languages in the past two decades which don’t do C++-style OOP _on purpose_. Julia is one of them.

---

<div class="post-metadata">

**Author:** ![DNF](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/dnf/32/10191_2.png) [@DNF](https://discourse.julialang.org/u/DNF)\
**Post date:** [June 12, 2020, 2:41pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/34 "2020-06-12T14:41:47Z")

</div>

> [@williamfgc](#):
>
> No issue at all. Just providing the reasoning that OO can be more productive in particular applications as it could avoid boilerplate to mimic OO that scales up quickly. Productivity is key in different industries that would like to give Julia a shot.

I think the central point is that the absence of class-based OOP and structural inheritance are not instances of _missing features_, but examples of _deliberate_ design choices. They are actively and intentionally avoided.

Whether these decisions are sound is of course open for debate, but the feeling of many Julia users is that Julia offers _more compelling_ patterns, and that introducing classic OOP would be detrimental to the composability which is typical of Julia packages, and _not_ so typical for OOP-based packages.

---

<div class="post-metadata">

**Author:** ![williamfgc](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/williamfgc/32/15445_2.png) [@williamfgc](https://discourse.julialang.org/u/williamfgc)\
**Post date:** [June 12, 2020, 3:13pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/35 "2020-06-12T15:13:02Z")

</div>

> To put it mildly, the link between OOP and productivity is yet to be demonstrated _across languages_ .

I’d take a step back a claim that C++ doesn’t force you to use OOP, it’s optional. Productivity doesn’t come from OOP itself, but from the options the user has to address a problem, C++ is mutil-paradigm, so it is the projects using C++ that decide what’s more productive to them, not the language itself. Many (listed previously) happen to use OOP/templates/functional programming as it is the combination that makes sense to them.

What I am getting at is essentially “we don’t allow and discourage OO, we give you better options in our view”. My 2 cents is to look at success stories (C++ evolves rapidly these days, being version 1 doesn’t mean we stopped evolving) and perhaps reconsider so several others can become active participants in Julia’s growth.

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [June 12, 2020, 3:16pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/36 "2020-06-12T15:16:39Z")

</div>

I believe that some of the softwares you mentioned would perhaps evolve differently if they had the choice. C++ was all the rage 20 years ago, and OO was good. These days the view of OO is much more moderated. The reasons are not that hard to demonstrate: consider for instance [The delightful conciseness of Julia](https://discourse.julialang.org/t/the-delightful-conciseness-of-julia/40947). With Julia we can accomplish anything we could produce with C++, and with more legible and grokkable code.

---

<div class="post-metadata">

**Author:** ![heliosdrm](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/heliosdrm/32/3851_2.png) [@heliosdrm](https://discourse.julialang.org/u/heliosdrm)\
**Post date:** [June 12, 2020, 3:32pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/37 "2020-06-12T15:32:47Z")

</div>

> [@williamfgc](#):
>
> What I am getting at is essentially “we don’t allow and discourage OO, we give you better options in our view”.

That statement does not represent correctly the answers given, in my opinion. There are various links to packages and documents that tell how to make that Julia objects work more in an “OO-fashion”, if you feel like doing it.

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [June 12, 2020, 3:34pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/38 "2020-06-12T15:34:17Z")

</div>

> [@williamfgc](#):
>
> Productivity doesn’t come from OOP itself, but from the options the user has to address a problem

The other way of looking at it is that the whole of C++ is so complicated that most people select a subset and use that. I don’t see this as an advantage; you will still encounter code from people who used some other part of the language.

> [@williamfgc](#):
>
> perhaps reconsider so several others can become active participants in Julia’s growth.

Sorry to be repetitive, but at this point in Julia’s lifecycle, it may take a lot more than generic statements like this for most people to even consider the possibility of taking this seriously.

You can’t “just add” C++-style OOP to Julia: the details of the semantics has to be worked out, then the issues with the compiler and optimization. And it has to be a large improvement in Julia’s usability, because it is a seriously breaking change. This is a lot of work, compared to the fuzzyness of the benefits that you are proposing — most Julia users are perfectly happy with this part of the language and would prefer to focus on other things.

Also, it is unclear that having some form of OOP would make more people contribute to Julia. Personally I would hope that if C++-style OOP is ever considered, someone would fork the language and continue without it (as you may have gathered, not all people are enthusiastic about C++ or OOP).

---

<div class="post-metadata">

**Author:** ![PetrKryslUCSD](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/petrkryslucsd/32/215825_2.png) [@PetrKryslUCSD](https://discourse.julialang.org/u/PetrKryslUCSD)\
**Post date:** [June 12, 2020, 3:37pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/39 "2020-06-12T15:37:29Z")

</div>

I just took a course in modern C++. What a pile of complexity! That is _not_ good. No wonder tools trying to cope with this complexity are all the rage. In Julia reading the code is in most cases good enough for me. Looking at deal.ii, I need all the help I can get.

---

<div class="post-metadata">

**Author:** ![williamfgc](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/williamfgc/32/15445_2.png) [@williamfgc](https://discourse.julialang.org/u/williamfgc)\
**Post date:** [June 12, 2020, 4:08pm UTC](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801/40 "2020-06-12T16:08:30Z")

</div>

> Sorry to be repetitive, but at this point in Julia’s lifecycle, it may take a lot more than generic statements like this for most people to even consider the possibility of taking this seriously.

Likewise, apologies if I sound repetitive, my point is that this is how languages evolved. C++ has the commitment to evolve rapidly post C++11 (not much was done between 98 and 11). Python 2 and Python 3 is another example. They look back and reconsider, the result is that those two languages dominate in many industries as their complexity allows for solving complex problems. They built large communities around.

> You can’t “just add” C+±style OOP to Julia:

> Also, it is unclear that having some form of OOP would make more people contribute to Julia.

Of course, I am not “demanding” OO to be available in the next release. I am just suggesting that perhaps the discussion is worth having and get different perspectives to answer those questions as many frameworks in scientific computing (hence their communities around) are familiar with OO and they see it as the proper way of doing things (even if some don’t, goes both ways). Perhaps Julia Con or surveys are a better place than discourse.

> most Julia users are perfectly happy with this part of the language and would prefer to focus on other things.

I guess it largely depends on the long term vision for Julia on either keeping current users perfectly happy or expand the base. Again, it is open to discussion.

In any case, I think Julia has a lot of great ideas put in practice I’d be happy to see the language grow. Part of it is taking feedback and being cool about it.

[Previous page](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801.md?page=1)

[Next page](https://discourse.julialang.org/t/about-inheritance-and-abstract-types/5801.md?page=3)