Going a bit on a tangent, I claim that object-oriented programming, at
least as embodied in C++, is not really suitable for scientific computing
and in fact has led certain codes to go astray.
To give a simple example, suppose you are told to write a 'matrix' class in
C++ that contains all the usual operations. You finish writing your class,
and a week later, you are told to derive 'symmetric matrices' as a subclass
of 'matrices'. This is trouble! Unless you wrote your original matrix
class in a very particular way, you will have a hard time writing a
symmetric matrix class that inherits from a matrix base class. This is not
just a theoretical example; I saw someone try to do this (unsuccessfully)
in a code he had written.
The problem with object-oriented programming is that you have make design
decisions when you write the base classes that lock you into a certain
path. This path may not be compatible with the flexibility needed for
scientific software projects.
I for one am glad that the designers of Julia decided not to make Julia an
object-oriented language, at least not in the C++ sense of the term.
-- Steve Vavasis
On Sunday, October 18, 2015 at 8:41:58 AM UTC-4, Sisyphuss wrote:
>
> 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.
>
>
>
>
