Julia: OOP or not

I'm working on Juno with Julia.

I don't know if Julia supports OOP or not.

For example, is there something like class or struct of c++?

How to declare it with members such as a data or a function?

When in doubt, read the documentation...

https://docs.julialang.org/en/v1/manual/types/#Composite-Types-1

Long story short:

struct MyType
    a::Int64
    b::Float64
end

x = MyType(3, 4)

x.a

EDIT: Methods are defined outside the type definition, e.g.

function double(x::MyType)
    x.a *= 2
end

Methods do not live inside the type, as they would do in C++ or Python, for example. This allows one of the key features of Julia, multiple dispatch, to work also with user-defined types, which are on exactly the same level as system-defined types.

Julia is not object-oriented in the full sense because you cannot attach methods to Julia's objects ("types"). The types do seem very similar to objects though. However, since they do not have their own associated methods and there is no inheritance the objects themselves don't do the acting. Instead you have functions which act on the objects.

The difference is ball.checkCollision() vs checkCollision(ball,Walls). In reality it's not that big of a deal. You can make something like inheritance by having a type have a field of another type, and multiple dispatch lets you write functions which do different things based on the objects you give them, which can be almost like object methods. The real difference is where you save the function and types in a file. So you can do a kind of quasi-objected-oriented style in Julia, but it's still distinctly different than OOP languages.

I would like to mention this worthfull conversation within Julia users group Julia and Object-Oriented Programming.
For me Julia is not like a conventional OO language, and I always like to think of Julia, as more a Method Oriented language that an Object Oriented one, that is because if you try to create an structure of encapsulated data and functionality in Julia, soon you will get yourself into trouble.

The answer is that Julia is closer to c rather than c++. Thus, OOP is limited in Julia having only c::struct rather than c++::class. Hence, it's just data encapsulation or data structure or customization of Types rather than true OOP objects, in the strict sense.

Yes. You just can't inherit from concrete "classes" with fields, only from abstract ones. This is because the memory layout of a concrete struct in Julia is part of its interface, and being able to subclass it by adding fields would break the Liskov substitution principle.

However, Functions with multiple dispatch are a strict generalization of methods with single dispatch and are strictly more polymorphic. You just have to define them outside of a class definition, because they can "belong" to multiple objects.

Traditional methods in an OO language are a special case of Julia functions where you only have dispatching based on the first argument.

I'm no expert on the language but my understanding is: Yes..and no.

It has the equivalent of classes and structs, however there are no methods on those objects other than a single constructor.

>In mainstream object oriented languages, such as C++, Java, Python and Ruby, composite types also have named functions associated with them, and the combination is called an “object”. In purer object-oriented languages, such as Python and Ruby, all values are objects whether they are composites or not. In less pure object oriented languages, including C++ and Java, some values, such as integers and floating-point values, are not objects, while instances of user-defined composite types are true objects with associated methods. In Julia, all values are objects, but functions are not bundled with the objects they operate on. This is necessary since Julia chooses which method of a function to use by multiple dispatch, meaning that the types of all of a function’s arguments are considered when selecting a method, rather than just the first one (see Methods for more information on methods and dispatch). Thus, it would be inappropriate for functions to “belong” to only their first argument. Organizing methods into function objects rather than having named bags of methods “inside” each object ends up being a highly beneficial aspect of the language design.