I'm not sure everyone would agree that Julia is "fully" object oriented.
Usually definitions of OOP include management of the data and not just the
interface. Specifically, there is no way to (currently) describe an
inheritance of variables.
While I personally would like Julia to have that feature, I don't think
it's necessary for languages to be fully OOP either. A lot of what's good
in C++ is functional.
On Sunday, October 18, 2015 at 2:32:06 PM UTC-4, Tobias Knopp wrote:
>
> Julia is fully object oriented. The core of OO is not to write a dot
> between an object and an associated function but that one has virtual
> functions. Multiple dispatch provides just that.
>
> Cheers
>
> Tobi
>
> Am Sonntag, 18. Oktober 2015 15:15:50 UTC+2 schrieb Simon Danisch:
>>
>> This design has at least 3 issues, since you can't have instances of a
>> module.
>> In general:
>> I personally would value the discussion of why Julia needs more OOP
>> constructs much more, If one can show that there are terrible flaws in
>> Julia's model which are swiftly solvable with OOP.
>> My guess is, that the argument "I learned X and can't transfer it to
>> Julia, so Julia needs to change", can't really convince anyone to start
>> implementing something rather involved.
>>
>> There are a lot of comments on people trying to bring OOP to Julia, which
>> are best summarized by: give Julia's model a chance and don't stick to OOP
>> - it will pay off.
>> And this kind of comment is pretty understandable in my opinion, since
>> Julia is quite a sophistaced language with plenty of constructs to avoid
>> OOP.
>> I don't see much value in OOP and Julia's multiple dispatch is actually
>> one of the things that brought me here ( I exclusively worked with OOP
>> languages before).
>> Besides the current flaws, I think it's a better model for numerical
>> computing, it yields concise code, easier maintenance and it's easier to
>> add feature to an existing code base than it is in OOP.
>>
>> I think Julia should move forward by not mimicking OOP further, but
>> instead improve the current model - there's lots to do already.
>> Wasting time by chasing after features from other languages will make it
>> much harder to turn Julia into a well rounded, sound language. (this only
>> applies to feature that get chased without a concrete problem)
>>
>> Best,
>> Simon
>>
>>
>> Am Sonntag, 18. Oktober 2015 14:41:58 UTC+2 schrieb Sisyphuss:
>>>
>>> When I'm learning Julia, I am always thinking what is the correct way to
>>> do OOP in this language. It seems to me that what I learned in C++ does not
>>> apply in Julia.
>>>
>>> It took me long to realize that the equivalent of Class of C++ in Julia
>>> is not Type, but Module. Module is the basic function unit in Julia.
>>>
>>> Thus, a Class in Julia is like
>>> module ClassName # class Name {
>>> using # include<> // should be outside
>>> import # include<>
>>> export function # public function;
>>> var = 1 # private static var;
>>> end # }
>>> This provides the same structure as C++.
>>>
>>> However, this design has two issues:
>>> 1) The visit control is not as fine-grained as in C++, the encapsulation
>>> is not strict;
>>> 2) Variables at the top level of a module are global variables.
>>>
>>> These two points are closely correlated. If we let module have private
>>> variables, then they are not too different from local variables, ans thus
>>> can be type inferred.
>>> I think this is a natural way to do OOP with Julia.
>>>
>>>
>>>
>>>
