On Thu, Sep 1, 2016 at 5:51 AM, lars klein <[email protected]> wrote:
> I'm currently revisiting Julia. > The language seems almost to good to be true. > > One thing that irks me is the lack of OOP. > Some time ago, I read up on all the information regarding this design > choice. > I don't want to debate it. Apparently that was a very informed and > conscious decision, to keep the language lean and fast. > > However, while coding in Julia, I thought about this. > > type Cat > age::Int > end > > type Tiger > innerCat::Cat > end > > > > In a "classical" OOP language, you would derive tiger from cat and say > that it's an "is-a" relationship. > In Julia, you have to use composition instead. > > Assuming you have an instance of type tiger, accessing the age of the > tiger becomes this. > > tiger.innerCat.age > > What about making the innerCat transparent ? > Like this: > > tiger.age > > Is that feasible ? > Since Julia is a compiled language, it seems to me like this would be a > simple job for the compiler. > I realize that there might be name-clashes in existing code. > But that could be prevented by implementing the rule: The field age is > searched top-down in the composite structure. > > I don't know the implications of this design change. > And I don't want to presume. > > Did you think about this ? > Did you decide not to include it, due to a specific reason ? > Is the feature more complex than I realize ? > > If this is possible, the next thing to consider would be adapting multiple > dispatch, too. > > function meow(c::Cat) > # age wasn't such a good field choice after all > println(age) > end > > > Maybe you could introduce the rule that > meow(tiger) > > is implicitly converted to > meow(tiger.cat) > > > Once again. > I know how it can be annoying to read the contributions of know-it-alls > that actually have no clue what is going on. > If you say "this is impossible", or even just "we can't do it in a nice > way", I have complete understanding. > > But right now I'm rather enthusiastic about these changes. > The second change should be possible via the compiler, too ? > Right now you have generic functions. I think that this already implies > lots of searching for adequate types. Searching in hierarchies of types > should be possible ? > > The two changes would effectively make Julia a first-class OOP language. > You could add a cat object to a tiger and the tiger would behave just like > a cat. > To my mind, this would be a great improvement in syntax. > While keeping the semantics easy to understand. > > The first change will be complicated. Changing the meaning of `.` is not as simple as just chaining the name space. Function call is a known complicated thing and it'll be very bad to make each field as expensive as a function call. The second change is basically impossible. It's agreed that the namespace should be improved and there should be some changes on this before 1.0. Simply allowing overloading `.` or changing the meaning of it in a way that makes it much more expensive is unlikely the way to go (although we might have something with similar function).
