>
>
> But I agree with Tobias and Simon - there is very little reason to try to
> make Julia more object-oriented. All the power you get from OO is still
> there, but you might need to think a little differently to harness it. If
> you have a concrete problem, along the lines of “this is how I’d do it in
> OO, but I don’t know how to do it in Julia”, the community is usually
> pretty good att figuring something out. A recent example was that someone
> wanted man.eat(food) rather than eat(man, food). A little thinking
> outside the box turned out the IMO superior solution - instead of changing
> the language to make it read better, just change the verb: feed(man, food)
> .
>
> Julia isn’t object-oriented, and will probably never be. But that doesn’t
> make it less powerful :)
>
>
Of course it doesn't make it less powerful, but it also doesn't alway lead
to nice code. The point of OOP isn't that it gets you more power, but it
gives you more maintainable code.
> On Sunday, October 18, 2015 at 8:32:06 PM UTC+2, 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.
>>>>
>>>>
>>>>
>>>>
>
