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!
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
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
end
@oodef struct B
b :: Int
end
@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
end
end
end
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.