Excellent idea. You should make a PR against the Scala GitHub repo and see how it goes.
On Wed, Oct 21, 2015 at 3:31 PM, <[email protected]> wrote: > How is the idea that any function defined with Julia tag gets into a first > class object with name *Julia* in a combined ScalaJulia language : > > *Julia* function sphere_vol(r) > > # julia allows Unicode names > <http://docs.julialang.org/en/latest/manual/unicode-input/> (in UTF-8 > encoding) > # so either "pi" or the symbol π can be used > return 4/3*pi*r^3end > > is translated into ScalaJulia language as: > > object *Julia* { > > def sphere_vol(r : Int) { > > return ( 4/3*pi*r^3 ) > > } > } > > > > Object Julia will get all first level functions defined in Julia syntax. > This is the simplest way to encapsulate > Julia functions and inherit in other Scala objects or classes in > ScalaJulia language. > > This will preserve simplicity and performance of Julia functions. > > SS > > > On Wednesday, October 21, 2015 at 10:00:25 AM UTC-7, Tom Breloff wrote: >> >> I think this discussion shows complementary definitions of traits: >> >> - verb-based traits: a type agrees to implement all the verbs >> appropriate to the given "verb trait" >> - noun-based traits: a type agrees to contain certain underlying data >> (and thus the getter/setter verbs could be implicitly defined for those >> fields) >> >> Whatever the final implementation of traits in Julia, I think keeping in >> mind this distinction could be helpful. >> >> On Wed, Oct 21, 2015 at 12:42 PM, Stefan Karpinski <[email protected]> >> wrote: >> >>> On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey <[email protected]> >>> wrote: >>> >>>> >>>> > 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. >>>> >>> >>> I do like this approach to composition/delegation, but it requires >>> automatically adding a lot of methods to the delegator, i.e. Unicycle in >>> this example, from all of its components, which feels kind of nasty and >>> dangerous, especially since we allow dynamic addition of methods >>> after-the-fact. In other words, you might add a method to Wheel, Frame or >>> Seat at any time, which would presumably then also apply to Unicycle >>> objects, potentially with unexpected consequences. It would be nice if the >>> delegation was more limited than that. Go doesn't have this problem since >>> you can't dynamically add methods – everything is known at compile time. >>> >> >>
