Well, I mean some "real" advantages beyond this small syntactical difference. In C++ there is a lot of mix between class methods and regular functions and it is good practice to only use class methods if this is really necessary, i.e. if access to private members is required.
One issue Julia seem to have is that it is not possible to subclass final types. This can be solved by turning the "is a" into a "has a" relation but currently there seem to be no way to carry over all generic methods from the member to the parent type. Am Mittwoch, 8. Januar 2014 16:47:50 UTC+1 schrieb John Myles White: > > I think part of the appeal of dot-notation OO is that it reads > left-to-right, which helps to make the code seem to read in the same order > as the sequence of actions taken. > > — John > > On Jan 8, 2014, at 7:45 AM, Tobias Knopp > <[email protected]<javascript:>> > wrote: > > > Would be interesting to see some use cases where "Java-like" OO better > fits than Julias OO. In C++ one can use both and usually choses based on > whether the dispatching can be done at runtime or at compile time (i.e. > classes with virtual function for runtime decisions and templates for > compile time decisions). > > There are many situations where I would have liked to use generic > programming in C++ but it was not possible as the type was only known at > runtime. In Julia this is no issue which makes it such a joy to use. > > > > > > Am Mittwoch, 8. Januar 2014 14:17:20 UTC+1 schrieb Stefan Karpinski: > > It's a bit hard to say whether Julia is object-oriented or not. I > suspect that for a lot of people, object-oriented means "do you write > `x.f(y)` a lot?" By that metric, Julia is not very object oriented. On the > other hand, everything you can do with single-dispatch o.o. in C++ or Java, > you can easily simulate with multiple dispatch, but you'll have to get used > to writing `f(x,y)` instead of `x.f(y)`. If your notion of > object-orientation has more to do with encapsulation and/or message > passing, then we start to look pretty non-o.o. again. > > > > > > On Wed, Jan 8, 2014 at 5:25 AM, Matthias BUSSONNIER < > [email protected]> wrote: > > > > Le 7 janv. 2014 à 21:48, Erik Engheim a écrit : > > > >> Thanks for the nice comments all of you. I guess I have to keep writing > more about my Julia experiences after this ;-) > >> > >> On Tuesday, January 7, 2014 9:39:05 PM UTC+1, Ivar Nesje wrote: > >> Great post, it sums up very well the things I think is the strengths of > Julia. > >> > >> A few notes: > >> Julia does not look up the method at runtime if the types of the > arguments to the function can be deduced from the types of the arguments to > the surrounding function (but it behaves that way for the user, unless he > redefines the method after the function was compiled #265). > >> > >> > >> That is cool I didn't know that. I assume this can make quite a big > difference in performance for tight inner loops. > > > > > > Some misc comment too : > > > > > Julia is not object oriented > > > > Is that True ? From the manual : > > > > > It is multi-paradigm, combining features of imperative, functional, > and object-oriented programming. > > > > I consider that Julia can be OO, the code just look different than in > other languages. > > > > > > Typo ? > > > Polymorphis lets you > > Missing m ? > > > > Liked the blog post too otherwise thanks, I would also have mentioned > code_lowered, code_llvm and code_typed > > not everyone is fluent assembler and those tool are really useful to, > especially in metaprogramming. > > > > -- > > M > > > >
