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 <ste...@karpinski.org
> <javascript:>> wrote:
>
>> On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey <tracey....@gmail.com
>> <javascript:>> 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.
>>
>
>
