[ANN] ObjectOriented.jl (renamed from TyOOP.jl), complete OOP support

Hi community! It has been quite a long time since my last post, and now I’m glad to say that I have completed my postgraduate career and started working with Julia! :sunglasses:

I made this package (EDIT) initially for the internal use in the company. It becomes open-source but I do get paid for this, which is pretty nice :partying_face:

Anyway, this package provides relatively complete object-oriented programming support for Julia. The design is mainly based on Python’s object-oriented programming, and adpated for Julia.

This is a simple example:

@oodef struct A  # mutable struct is allowed
    a :: Int

@oodef struct B
    b :: Int

@oodef struct C <: {A, B}
    c :: String
    function new(a::Int, b::Int, c::String = "somestring")
        @mk begin
            A(a), B(b)  # call base class constructors
            c = c       # init field

c = C(1, 2)
@assert c.a === 1
@assert c.b === 2

And this is the feature list:

feature support notes
inheritance yes upcasts/downcasts are not supported
overloaded constructors and methods yes based on multiple dispatch
multiple inheritance yes MRO based on C3
Python-style properties yes
default field values yes
generics yes
interfaces yes singleton struct types as base classes
modifiers no just like Python
static class methods no won’t fix to avoid type piracy
metaclasses no won’t fix in favour of macros

Note that I’m not against multiple dispatch.

Actually, this package comes with an article Translating OOP into Idiomatic Julia · ObjectOriented.jl (EDIT), to show that Julia’s multiple dispatch and the type system are powerful enough to translate code wriiten in OOP mechanically and completely.

TyOOP also provides interface programming support to export APIs in idiomatic julia and avoid abstraction leakage of the OOP code. We hope the downstream users of packages using TyOOP unaware of OOP stuffs. Please check out this machine learning example: making a ScikitLearnBase API compatible model using LsqFit.jl (EDIT).

There are still unsolved issues of using OOP. Using TyOOP in scenarios that are suitable for vtable-based polymorhism, is still slow due to dynamic dispatch. Using the backedges (like Valsplit.jl) is possible to speed up processing containers of abstract typed element, but there are other issues. If you get interested we might discuss.

P.S: The prefix of the package’s name Ty is just the abbreviation of the company’s name. If you have comments, please reply here… The package is not registered yet and we might rename it if necessary.


The documentations (EDIT:) Home · ObjectOriented.jl

I don’t do much OOP, but it’s a very popular programming model. I expect this will be useful to lots of people, especially coming from languages like Python. I could also see a lot of value in something like this for making it easier to translate code from such languages.

Congrats on the new job!!


Thanks, Chad! This project is not only for providing OOP support, it also tells people that Julia CAN do OOP smoothly.

I think we have already found the suitable programming model for Julia since a long time ago, but it might be useful if we use this package to show the power of Julia.


Hi. Welcome back. I imagine your package will get a good deal of attention, especially from people who have mostly used OO programming. It may be more straightforward (and more easily searched) to use a name like ObjectOriented.jl.


Thanks for the suggestion! I’ve received some similar comments, all of which are reasonable. I will negotiate with my tech leader today.


My tech leader has agreed on renaming the package. It can be TyObjectOriented.jl, though we prefer a prefix Ty. Would this be fine? Any idea? @JeffreySarnoff @Palli

Personal preference: ObjectOriented.jl > TyOOP.jl > TyObjectOriented.jl. I would keep everything as abbreviations or keep everything as full words.

But I guess your tech leader will want Ty to appear in all your future package names? :grinning: I suspect there are better ways to promote your company within the Julia ecosystem, e.g. printing out a banner showing the company / developer name when the package is loaded?


Congratulations on the package! The documentation is very nice.

As for the name, I think TyObjectOriented.jl is quite good and should still be searchable. The Ty prefix makes it clear that this is an implementation without claiming to be the implementation. A broader ObjectOriented.jl implies that it represents all of OOP, or perhaps an umbrella package that gives many choices.


Thanks for your feedback. I just got reminded that there does have some naming rules for Julia packages. I will go to persuade my tech leader next Monday.

Besides, I think the company (Suzhou-TongYuan) just wants to let people know that they are willing to contribute and hope to gain more attention. I’ll discuss more with the tech leader about these stuffs (things other than tech are too tiring😔).

1 Like

Thanks for your feedback, and you’ve post a good idea for Ty. Your thought is true as we could have other OOP implementations.

For example, so far we use Python-style OOP since it’s more familiar to the scientific computing world.

However, Python-style OOP has some issues when inheriting multiple interfaces, it is not the perfect one. In C# or Java, it is possible for you to inherit both IList<int> and IList<char> which makes your type works like both, and you can access different list push methods individually for IList<int> and IList<char>, these methods are not the same one; but in Python, the same-name method is always the same.

Hence having OOP more of C#/Java is quite possible, our project is actually an instance of all valid OOP implementations.

Anyway, I will try to discuss this again with my tech leader. Fortunately, he is a kind person working on the tech side as well.


Ahh, bikeshedding at its best…

Great work, @thautwarm , even though I am glad to be rid of OOP, and I am not coming back! :wink:


I understand wanting to tie the company to this software, developed on their time. Other companies have solved
this by creating an Company github site that is used to house any open source code (see Invenia and PkgTemplates.jl. That way every time someone looks at the source code they see the company info.

Microsoft has contributed an open source Julia package. They way they handle this may be instructive:
they created a github account “microsoft”
the software package has its home there
Both the source code and the documentation identify them:

OpticSim.jl is a Julia package for geometric optics (ray tracing) simulation and optimization of complex optical systems developed by the Microsoft Research Interactive Media Group and the Microsoft Hardware Architecture Incubation Team (HART).

Nobody is going to use this package without looking at the README and docs. There could be a short acknowledgement of (and identification of) the company in both places. Placing the company’s id “Ty” at the start of the name will work against having the most people be aware of (and grateful for) the contribution that the company is making – simply because most search engines favor matches at the beginning of a string. Search “ObjectOriented AND Julia” and btw searching “TyOOP” is particularly unhelpful.

Today, most searching for Julia packages happens using https://juliahub.com/ , your employer should want this package to appear very near the top, if not at the top of searches there for Object and Object Oriented. “Ty” pulls up all the packages which are about “Types” (there are many).

We all understand the company’s interest, and respect them for supporting this contribution. Please understand that none of my suggestions are designed to minimize their association and recognition. I am suggesting ways that I would use in their position to get the most benefit.


Actually there are many many packages, where the name doesn’t give any hint on what they do. Even the most recognized packages don’t have a speaking name. You would never search for their name if looking for their purpose. There are much worse names in the ecosystem than putting “Ty” in front. But of course, naming it clean and clear helps to make packages findable, to which degree, I don’t know. A good Readme.md on the github front is probably more important.


I have converged with my tech leader: now we’re all okay with removing the prefix Ty!

However, the idea from @apo383 is also important: this package shall not claim that it is the only OOP implementation. ObjectOriented.jl makes it too general, and we want to use a more specific name.

Hence, we want to collect ideas of alternative names in the community. It could be nice if we can work together with the community to make an appropriate and neat package name.

Any ideas? @JeffreySarnoff or anyone else?


ObjectOriented.jl +1


Since this is the first approximation anyone makes to a full Object Oriented Julia, you can call it that way without too much overthinking. Let others that may follow this path choose new names inventively!


This is a really cool package, thank you for sharing it. While I’m really not so keen on the whole OOP stuff, I do indeed think that type/field inheritance (like the example in this post) might be really nice for ABMs (my main field of research). So maybe this is something to try out in the future to see how well it works for my use case. :slight_smile:

While reading through the docs, I’ve stumbled upon something that frankly bugs me a bit though. As outlined here, regular type checks in Julia like

Snake <: Animal # false

just don’t work… Instead one needs to rely on specific methods like

issubclass(Snake, Animal) # true

which is kind of a no-go for me because it would require adaptation of “basic” Julia code when using the TyOOP.jl package. :confused:

1 Like

Does FromPythonOOP sound like a good name?

My understanding of this package is that people still need to learn to code the native Julia style (multiple dispatches + type stability) to fully take advantage of Julia. But this package gives a rather smooth experience for users that have strong (Python) OOP backgrounds. In this sense, it’s from Python to Julia.


If you do not use ObjectOriented.jl, someone else will. Your work is exemplary, and if you plan to keep up with it – the better choice is that you use the name.