On Tuesday, October 20, 2015 at 3:39:00 PM UTC-6, Stefan Karpinski wrote:
>
> ScalaJulia is a skunkworks project Martin and I have been working on for a
> while now. The hardest part so far has been deciding between whether to
> call it ScalaJulia or JuliaScala. Other names we considered: Julala, Scalia.
The US Supreme Court may get involved if you call it Scalia. Hard to know
in which direction.
> Above, a relatively simple macro can replace all the "Type..." with the
fields of the composed types, applying multiple inheritance of the
structures without the baggage required in classic OOP. Then you can
compose your type from other types, but without having to write
"unicycle.wheel.radius"... you can just write "unicycle.radius".
As Stefan mentioned, Go is not traditional OO. This "composition-based"
approach is part of Go's OO approach. In go, a type can have named fields
of different types (like most OO languages), but also has "embedding". For
example, if one declared
type Unicycle struct {
Wheel
Frame
Seat
}
then you could access the individual fields directly. So, if "u' is of type
Unicycle, then you could access/set u.Cushiness directly. Similarly, if the
embedded types had methods, i.e. frame.Color(), they can be called directly
through unicycle, u.Color(). This is similar to, but distinct from,
inheritance (the difference is that the Unicycle type doesn't actually have
these fields, just the ability to call them easily, which is significant
because of interfaces). In the case of clashes, the program must specify
which is meant, so if both Seat and Frame had a Color() method, the user
would have to specify u.Frame.Color vs. u.Seat.Color. In Go, this is
handled by the compiler, and would need to be handled somewhere in the
Julia runtime/REPL. It's a very nice paradigm, but would have to be made to
fit within the broader Julia context.
