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.
>
>
>
>
