As for class composition, this is how Scala does it:
http://www.scala-lang.org/old/node/117
I've previously suggested introducing a `trait` label as to keep type and
dispatch information separate. Thus you could do:
trait A
x::Int64
y::Int64
end
trait B
z::Int64
end
type foo(A, B) <: bar
# ...
end
It would then be natural to hang interfaces on traits (thus, instead of
assuming a variable exists, you could specify an interface applies to a
trait)
# only classes that mix-in trait B can call this function
get_x{C <: B}(b::C) = b.x
get_y{C <: B}(b::C) = b.y
That's my $0.02.
On Tuesday, October 20, 2015 at 2:42:37 PM UTC-4, [email protected]
wrote:
>
> It is a suggestion. There is no project. If some of the experts agree on
> such a combined language in this group, a combined grammar
> can be created and ScalaJulia functional language can be implemented
> through a project.
>
> We need some exchange of ideas. Such a combined language has implication
> for Spark, Hadoop, Mlib and many other things to be integrated
> faster with Julia.
>
> SS
>
>
> On Tuesday, October 20, 2015 at 4:40:23 AM UTC-7, Sisyphuss wrote:
>>
>> I'm sorry, but I didn't find the ScalaJulia project as you mentioned.
>>
>>
>> On Monday, October 19, 2015 at 7:39:04 PM UTC+2, [email protected]
>> wrote:
>>>
>>> I am confident that a new OOP language *ScalaJulia *is possible
>>> integrating syntax of both functional languages Scala and Julia.
>>> Thanks,
>>> SS
>>>
>>> On Sunday, October 18, 2015 at 5:41:58 AM UTC-7, Sisyphuss wrote:
>>>>
>>>> When I'm learning Julia, I am always thinking what is the correct way
>>>> to do OOP in this language. It seems to me that what I learned in C++ does
>>>> not apply in Julia.
>>>>
>>>> It took me long to realize that the equivalent of Class of C++ in Julia
>>>> is not Type, but Module. Module is the basic function unit in Julia.
>>>>
>>>> Thus, a Class in Julia is like
>>>> module ClassName # class Name {
>>>> using # include<> // should be outside
>>>> import # include<>
>>>> export function # public function;
>>>> var = 1 # private static var;
>>>> end # }
>>>> This provides the same structure as C++.
>>>>
>>>> However, this design has two issues:
>>>> 1) The visit control is not as fine-grained as in C++, the
>>>> encapsulation is not strict;
>>>> 2) Variables at the top level of a module are global variables.
>>>>
>>>> These two points are closely correlated. If we let module have private
>>>> variables, then they are not too different from local variables, ans thus
>>>> can be type inferred.
>>>> I think this is a natural way to do OOP with Julia.
>>>>
>>>>
>>>>
>>>>
