I’ve never seen a problem that foo.bar(x,y) can solve, but bar(foo, x, y)
can’t.
There *are* things, however, that are pretty easy to do in OO languages
that can’t be done in Julia; one such thing is adding/changing behavior
through inheritance. That’s pretty easy to work around, though - instead of
the following (which won’t work in Julia, but using Julia syntax to make
comparison easier)
immutable Foo
x
end
foo(f::Foo) = f.x)
bar(f::Foo) = 2 * f.x
immutable Bar <: Foo
y
end
bar(b::Bar) = b.y * b.x
where Bar has an x field inherited from Foo, and overrides behavior for the
bar function, you can easily do this:
abstract AbstractFoo
immutable Foo
x
end
foo(f::Foo) = f.x
bar(f::Foo) = 2 * f.x
immutable Bar
y
f::Foo
end
foo(b::Bar) = foo(b.f)
bar(b::Bar) = b.y * b.f.x
In other words, by using *composition* instead of inheritance, you can
extend and amend the behavior of any object with all the power you have in
inheritance. (You could also create an abstract type that both Foo and Bar
inherits, to make them part of the same type tree and make dispatch a
little simpler.) This is heavily relied on in a couple of recent additions
to Interpolations.jl, that provide axis scaling and extrapolation through
composition - had I written that code in Java or C# (or C++), I probably
would have used inheritance instead.
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 :)
// T
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.
>>>
>>>
>>>
>>>
