Re: [julia-users] Julia and Object-Oriented Programming

[Brendan Tracey]

On Friday, October 23, 2015 at 7:38:37 AM UTC-6, Abe Schneider wrote:
>
> An OO approach is really just specifying an interface in a formal manner. 
> The second you write any type of interface, you always risk making a choice 
> that will haunt you down the road. I don't see the difference between:
>
> class Foo {
>   float getX() { ... }
>   float getY() { ... }
> }
>
> and:
>
> type Foo { ... }
> function getX(f::Foo) -> float { ... }
> function getY(f::Foo) -> float { ... }
>
> except that an instance of `foo` is being passed implicitly in the first 
> case. To that extent, I would say Julia OO (i.e. on the dispatching). Where 
> it is not OO is in the layout of the data.
>

In some  languages there is no difference. In Go, a method is exactly a 
function that can be called with a special syntax. One can do

c := mat64.NewDense(5, 5, nil)
c.Mul(a, b)
 
or one can do
(*mat64.Dense).Mul(c, a, b)

There aren't many cases where one would actually want to do the latter, but 
it makes the definition of behavior clear.

I think the difference in Julia would be the interaction with multiple 
dispatch. In the former case, it seems like getX would live in its own 
namespace (only accessible through the Foo class), while in the latter case 
it would add to the many definitions of getX.


It is true that with a more OO language, because of its formalism, you run 
> the risk of declaring variable types in a parent class that might not be 
> correct in the child classes, so some planning is required. However, what 
> you gain is better code in the long run. For example, I might have:
>
> abstract Baz
>
> type Foo <: Baz {
>   x::Float
> }
>
> type Bar <: Baz {
>   x::Float
> }
>
> and an interface:
>
> getX{T <: Baz}(b::T) -> Float = b.x
>
>
> which works fine, except maybe someone else comes along and writes:
>
> type Blob <: Baz {
>   myX::Float
> }
>
> Now to fix your interface, you have to write a separate `getX` for `Blob`. 
> This might not seem like a big deal, except you might not catch this issue 
> until run time (I don't think there is a way a static-checker could 
> identify the problem). Imagine a large library or base of code, with many 
> people working on the code, and you suddenly are exposed to a large number 
> of issues.
>

This seems more like an issue of compiler vs. no compiler issue than one 
with OO vs. multiple dispatch.
 
You can do OO without inheritance (or OO like things if your definition of 
OO includes inheritance). In Go, one would define 

type GetXer interface {
 GetX() float64
}

I could then write a function
func SquareX(g GetXer) float64 {
 v := g.GetX()
 return v * v
}

Now, any type that has a GetX method can be passed to SquareX. There is no 
inheritance necessary to make this happen.

Re: [julia-users] Julia and Object-Oriented Programming

[Abe Schneider]

An OO approach is really just specifying an interface in a formal manner. 
The second you write any type of interface, you always risk making a choice 
that will haunt you down the road. I don't see the difference between:

class Foo {
  float getX() { ... }
  float getY() { ... }
}

and:

type Foo { ... }
function getX(f::Foo) -> float { ... }
function getY(f::Foo) -> float { ... }

except that an instance of `foo` is being passed implicitly in the first 
case. To that extent, I would say Julia OO (i.e. on the dispatching). Where 
it is not OO is in the layout of the data.

It is true that with a more OO language, because of its formalism, you run 
the risk of declaring variable types in a parent class that might not be 
correct in the child classes, so some planning is required. However, what 
you gain is better code in the long run. For example, I might have:

abstract Baz

type Foo <: Baz {
  x::Float
}

type Bar <: Baz {
  x::Float
}

and an interface:

getX{T <: Baz}(b::T) -> Float = b.x


which works fine, except maybe someone else comes along and writes:

type Blob <: Baz {
  myX::Float
}

Now to fix your interface, you have to write a separate `getX` for `Blob`. 
This might not seem like a big deal, except you might not catch this issue 
until run time (I don't think there is a way a static-checker could 
identify the problem). Imagine a large library or base of code, with many 
people working on the code, and you suddenly are exposed to a large number 
of issues.

This is why people advocate OOP. In the first definition of `Foo`, I know 
it will always have an `x`, and I can easily see the interface necessary to 
access it.

So, yes, an OO usually requires more work up-front. If Julia is meant to be 
purely scientific language which requires a code rewrite for real-world 
use, then I won't argue with not having a way to compose the data. However, 
in any project of medium to large complexity, it will make life much more 
difficult not having that capability.

On Thursday, October 22, 2015 at 4:00:36 PM UTC-4, vav...@uwaterloo.ca 
wrote:
>
> One way to build a code-base that everyone can share is to specify 
> interfaces to datatypes as in methods in C++ base classes.  Another way is 
> for each individual to write his/her own code, and then read everyone 
> else's code, and then meet at coffee shops and talk on the phone to get 
> things to work together.  I am claiming that the second way is better for 
> scientific software than the first way because scientific software is more 
> open-ended than, say, systems software.  I am claiming that specifying 
> interfaces from the outset can lead to prematurely locking in design 
> decisions, and that I have seen examples of this in the real world.  Keep 
> in mind that Julia is being touted as a suitable language for both the 
> initial and the later phases of scientific software development.
>
> In the event that Julia adds new OO or other interface-specifying 
> features, obviously it would be possible for a team to ignore them, at 
> least initially.  But I have also seen in previous projects that there is a 
> tendency for people (including me) to jump onto the fanciest possible 
> solution offered by the programming language to solve a software design 
> problem.
>
> -- Steve Vavasis
>
>
> On Thursday, October 22, 2015 at 12:02:21 PM UTC-4, g wrote:
>>
>> What is the other option here? It seemed like with the OO/Julia way you 
>> are complaining about you at least have working (but slow) code handling 
>> your new polynomial type. In a case where your new type doesn't work with 
>> "obtainCoefficient", it won't 
>> work with any of your other code either. You would just have no working 
>> code with your new polynomial type. How is that better?
>>
>> But the next week, someone asks whether you can handle polynomials 
>>> specified as p(x)=det(A-x*B), where A and B are n-by-n matrices.  For 
>>> polynomials in this format, "obtainCoefficient" is expensive and would not 
>>> be regarded as a simple "getter" operation.  If many people had already 
>>> written functions invoking the 'obtainCoefficient' method, then you would 
>>> be stuck.  You would retrospectively realize that the obtainCoefficient 
>>> member function was not a good idea.  This example is typical of open-ended 
>>> scientific software projects.
>>>

Re: [julia-users] Julia and Object-Oriented Programming

[Abe Schneider]

Ah, okay, that is different then. What's the advantage of creating a new 
method versus copying the fields? I would imagine there is a penalty with 
each deference you have to follow in order to make that work.


I'm not familiar with Scala, so sorry if I'm telling you something you 
> know, but in go the member variables and methods are not copied over. The 
> Unicycle struct in go does not itself have those fields, the fields of the 
> struct do. In other words, defining
>
> type Unicycle struct {
> Frame
> Wheel
> Seat
> } 
>
> Is exactly like declaring 
>
> type Unicycle struct {
>Frame Frame
>Wheel Wheel
>SeatSeat
> } 
>
> except that in the former case one can call unicycle.Cushiness() , and in 
> the latter one must call unicycle.Seat.Cushiness(). In particular, if you 
> swap out one Frame in the unicycle for a different Frame, the field values 
> change (the methods won't, since methods are with a type).
>

Re: [julia-users] Julia and Object-Oriented Programming

[ssarkarayushnetdev]

Inheritance should be understood in terms of properties (and operations on 
properties) of a classes and sub-classes.  In functional programming 
language,
application of functions like *func_1*(x, y, *func_2*(z, p)) is implicitly 
exploiting the idea of inheritance. Making such relationships explicit
in programming languages will lead to much less errors at run time with 
compile time ( definition and declaration ) checks.


On Friday, October 23, 2015 at 7:59:26 AM UTC-7, Brendan Tracey wrote:
>
> On Friday, October 23, 2015 at 7:38:37 AM UTC-6, Abe Schneider wrote:
>>
>> An OO approach is really just specifying an interface in a formal manner. 
>> The second you write any type of interface, you always risk making a choice 
>> that will haunt you down the road. I don't see the difference between
>>
>> class Foo {
>>   float getX() { ... }
>>   float getY() { ... }
>> }
>>
>> and:
>>
>> type Foo { ... }
>> function getX(f::Foo) -> float { ... }
>> function getY(f::Foo) -> float { ... }
>>
>> except that an instance of `foo` is being passed implicitly in the first 
>> case. To that extent, I would say Julia OO (i.e. on the dispatching). Where 
>> it is not OO is in the layout of the data.
>>
>
> In some  languages there is no difference. In Go, a method is exactly a 
> function that can be called with a special syntax. One can do
>
> c := mat64.NewDense(5, 5, nil)
> c.Mul(a, b)
>  
> or one can do
> (*mat64.Dense).Mul(c, a, b)
>
> There aren't many cases where one would actually want to do the latter, 
> but it makes the definition of behavior clear.
>
> I think the difference in Julia would be the interaction with multiple 
> dispatch. In the former case, it seems like getX would live in its own 
> namespace (only accessible through the Foo class), while in the latter case 
> it would add to the many definitions of getX.
>
>
> It is true that with a more OO language, because of its formalism, you run 
>> the risk of declaring variable types in a parent class that might not be 
>> correct in the child classes, so some planning is required. However, what 
>> you gain is better code in the long run. For example, I might have:
>>
>> abstract Baz
>>
>> type Foo <: Baz {
>>   x::Float
>> }
>>
>> type Bar <: Baz {
>>   x::Float
>> }
>>
>> and an interface:
>>
>> getX{T <: Baz}(b::T) -> Float = b.x
>>
>>
>> which works fine, except maybe someone else comes along and writes:
>>
>> type Blob <: Baz {
>>   myX::Float
>> }
>>
>> Now to fix your interface, you have to write a separate `getX` for 
>> `Blob`. This might not seem like a big deal, except you might not catch 
>> this issue until run time (I don't think there is a way a static-checker 
>> could identify the problem). Imagine a large library or base of code, with 
>> many people working on the code, and you suddenly are exposed to a large 
>> number of issues.
>>
>
> This seems more like an issue of compiler vs. no compiler issue than one 
> with OO vs. multiple dispatch.
>  
> You can do OO without inheritance (or OO like things if your definition of 
> OO includes inheritance). In Go, one would define 
>
> type GetXer interface {
>  GetX() float64
> }
>
> I could then write a function
> func SquareX(g GetXer) float64 {
>  v := g.GetX()
>  return v * v
> }
>
> Now, any type that has a GetX method can be passed to SquareX. There is no 
> inheritance necessary to make this happen.
>
>

Re: [julia-users] Julia and Object-Oriented Programming

[Brendan Tracey]

On Friday, October 23, 2015 at 7:22:28 AM UTC-6, Abe Schneider wrote:
>
> Ah, okay, that is different then. What's the advantage of creating a new 
> method versus copying the fields? I would imagine there is a penalty with 
> each deference you have to follow in order to make that work.
>

The advantage is simplicity. A unicycle is a Frame, a Seat, and a Wheel, no 
more, no less (unless we added more to the definition of course).  
Inheritance gets complicated fast in C++ (again, can't speak for Scala) 
with virtual functions, virtual vs. nonvirtual descructors. Additionally, 
Unicycle doesn't inherit from anything. It's not a subclass of anything. It 
can be used however. 

As to dereferencing, types in Go are not boxed like in Java (for example). 
We could construct Unicycle as 
type Unicycle struct {
 Frame
 Seat
 Wheel
}

or as 
type Unicycle struct {
 *Frame
 *Seat
 *Wheel
}

or any combination you'd like. In the latter case they are pointers, and in 
the former they are not. So, first of all you can avoid the dereferencing 
by not having pointers. Secondly, in Go all of the types are known at 
compile type, so I believe you can call the function without going through 
extra deferencing, even in the case where they are pointers.

Re: [julia-users] Julia and Object-Oriented Programming

[ssarkarayushnetdev]

This is where Object Oriented programming can be useful.  If you define a 
Trait and then several abstract classes extending the trait at many levels, 
it will be
possible to define complex polynomial ( p(x)=det(A-x*B) ) specific abstract 
classes at deeper levels for computing coefficients. OOP constructs will
make super-classes and traits to be reusable for lower level abstract 
classes.  A type or operations on a type can both be abstract. 
 Mathematicians
can exploit the power of OOP if the nested structures in mathematical 
expressions are understood properly for writing programs.


On Wednesday, October 21, 2015 at 12:43:17 PM UTC-7, vav...@uwaterloo.ca 
wrote:
>
> Earlier I posted a statement in this thread that object-oriented 
> programming is in many cases not suitable for scientific software because 
> it forces the designer to make decisions too early in the design process 
> that become unwelcome constraints as the project progresses.  
>
> If I understand what people are saying about traits, they may pose the 
> same danger.  Just to give a simple example, suppose you are designing a 
> class for univariate polynomials over a ring K.  You might expect that you 
> will need both dense and sparse (i.e., most coefficients=0) polynomials, so 
> you might create an abstract class for both dense and sparse polynomials. 
>  In current Julia you might write:
>
> abstract UnivariatePolynomial{T}
>
> where T is the underlying ring.  You would specify nothing else.  Now if 
> 'traits' were available as a language feature, you might create a member 
> function "obtainCoefficient" that would work properly for both sparse and 
> dense polynomials.
>
> But the next week, someone asks whether you can handle polynomials 
> specified as p(x)=det(A-x*B), where A and B are n-by-n matrices.  For 
> polynomials in this format, "obtainCoefficient" is expensive and would not 
> be regarded as a simple "getter" operation.  If many people had already 
> written functions invoking the 'obtainCoefficient' method, then you would 
> be stuck.  You would retrospectively realize that the obtainCoefficient 
> member function was not a good idea.  This example is typical of open-ended 
> scientific software projects.
>
> So again, I would be wary of adding object-oriented features to Julia, at 
> least until the language matures a bit more mature.
>
> I have been on the other side of this fence already: I wrote the code for 
> SortedDict in DataStructures.jl.  I had a mandate from Kevin Squire to make 
> SortedDict a drop-in replacement for Dict.  Since there is no formal 
> interface for 'Dict' defined, and indeed, Julia does not have a  means to 
> specify interfaces, this means that I actually have to read all the code in 
> associative.jl and dict.jl in order to carry out Kevin's mandate.  But this 
> turns out to be not so hard!
>
> -- Steve Vavasis
>
>
>
>
>
>
> On Wednesday, October 21, 2015 at 1:00:25 PM UTC-4, 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  
>> wrote:
>>
>>> On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey  
>>> 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() 

Re: [julia-users] Julia and Object-Oriented Programming

[ssarkarayushnetdev]

I found that you are one of the core developers of Julia language. Could 
you please explain how Julia compiler and executor can be called
through APIs ?  Are there any documentations for APIs. 
Is it possible to call Julia compiler and executor through programming 
interfaces from Scala compiler / executor ?  I am 
trying to understand broad strategy for possible implementation of 
ScalaJulia language.

On Wednesday, October 21, 2015 at 12:41:49 PM UTC-7, Stefan Karpinski wrote:
>
> 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,  
> 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 
>>  (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 >> > wrote:
>>>
 On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey  
 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.

>>>
>>>
>

Re: [julia-users] Julia and Object-Oriented Programming

[vavasis]

One way to build a code-base that everyone can share is to specify 
interfaces to datatypes as in methods in C++ base classes.  Another way is 
for each individual to write his/her own code, and then read everyone 
else's code, and then meet at coffee shops and talk on the phone to get 
things to work together.  I am claiming that the second way is better for 
scientific software than the first way because scientific software is more 
open-ended than, say, systems software.  I am claiming that specifying 
interfaces from the outset can lead to prematurely locking in design 
decisions, and that I have seen examples of this in the real world.  Keep 
in mind that Julia is being touted as a suitable language for both the 
initial and the later phases of scientific software development.

In the event that Julia adds new OO or other interface-specifying features, 
obviously it would be possible for a team to ignore them, at least 
initially.  But I have also seen in previous projects that there is a 
tendency for people (including me) to jump onto the fanciest possible 
solution offered by the programming language to solve a software design 
problem.

-- Steve Vavasis


On Thursday, October 22, 2015 at 12:02:21 PM UTC-4, g wrote:
>
> What is the other option here? It seemed like with the OO/Julia way you 
> are complaining about you at least have working (but slow) code handling 
> your new polynomial type. In a case where your new type doesn't work with 
> "obtainCoefficient", it won't 
> work with any of your other code either. You would just have no working 
> code with your new polynomial type. How is that better?
>
> But the next week, someone asks whether you can handle polynomials 
>> specified as p(x)=det(A-x*B), where A and B are n-by-n matrices.  For 
>> polynomials in this format, "obtainCoefficient" is expensive and would not 
>> be regarded as a simple "getter" operation.  If many people had already 
>> written functions invoking the 'obtainCoefficient' method, then you would 
>> be stuck.  You would retrospectively realize that the obtainCoefficient 
>> member function was not a good idea.  This example is typical of open-ended 
>> scientific software projects.
>>
>>>
>>>

Re: [julia-users] Julia and Object-Oriented Programming

[Spencer Russell]

Julia has a well-developed C API, so you can embed it inside other 
applications. Info on using it is here:
http://docs.julialang.org/en/release-0.4/manual/embedding/ 


-s

> On Oct 22, 2015, at 3:07 PM, ssarkarayushnet...@gmail.com wrote:
> 
> I found that you are one of the core developers of Julia language. Could you 
> please explain how Julia compiler and executor can be called
> through APIs ?  Are there any documentations for APIs. 
> Is it possible to call Julia compiler and executor through programming 
> interfaces from Scala compiler / executor ?  I am 
> trying to understand broad strategy for possible implementation of ScalaJulia 
> language.
> 
> On Wednesday, October 21, 2015 at 12:41:49 PM UTC-7, Stefan Karpinski wrote:
> 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,  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 
>  (in UTF-8 
> encoding)
> # so either "pi" or the symbol π can be used
> return 4/3*pi*r^3
> end
> 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 > 
> wrote:
> On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey > 
> 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.
> 
> 

Re: [julia-users] Julia and Object-Oriented Programming

[ssarkarayushnetdev]

It is very nice to exchange thoughts with mathematicians. If classes, 
instances, types, inheritance, polymorphism and many other things in OOP 
were derived from concepts in mathematics then there should be no 
contradiction between scientific computing and OOP.  It is just matter of 
correct interpretation to relate mathematical model to programming model.

On Thursday, October 22, 2015 at 1:00:36 PM UTC-7, vav...@uwaterloo.ca 
wrote:
>
> One way to build a code-base that everyone can share is to specify 
> interfaces to datatypes as in methods in C++ base classes.  Another way is 
> for each individual to write his/her own code, and then read everyone 
> else's code, and then meet at coffee shops and talk on the phone to get 
> things to work together.  I am claiming that the second way is better for 
> scientific software than the first way because scientific software is more 
> open-ended than, say, systems software.  I am claiming that specifying 
> interfaces from the outset can lead to prematurely locking in design 
> decisions, and that I have seen examples of this in the real world.  Keep 
> in mind that Julia is being touted as a suitable language for both the 
> initial and the later phases of scientific software development.
>
> In the event that Julia adds new OO or other interface-specifying 
> features, obviously it would be possible for a team to ignore them, at 
> least initially.  But I have also seen in previous projects that there is a 
> tendency for people (including me) to jump onto the fanciest possible 
> solution offered by the programming language to solve a software design 
> problem.
>
> -- Steve Vavasis
>
>
> On Thursday, October 22, 2015 at 12:02:21 PM UTC-4, g wrote:
>>
>> What is the other option here? It seemed like with the OO/Julia way you 
>> are complaining about you at least have working (but slow) code handling 
>> your new polynomial type. In a case where your new type doesn't work with 
>> "obtainCoefficient", it won't 
>> work with any of your other code either. You would just have no working 
>> code with your new polynomial type. How is that better?
>>
>> But the next week, someone asks whether you can handle polynomials 
>>> specified as p(x)=det(A-x*B), where A and B are n-by-n matrices.  For 
>>> polynomials in this format, "obtainCoefficient" is expensive and would not 
>>> be regarded as a simple "getter" operation.  If many people had already 
>>> written functions invoking the 'obtainCoefficient' method, then you would 
>>> be stuck.  You would retrospectively realize that the obtainCoefficient 
>>> member function was not a good idea.  This example is typical of open-ended 
>>> scientific software projects.
>>>

Re: [julia-users] Julia and Object-Oriented Programming

[ssarkarayushnetdev]

Thank you for the link. I guess an intermediate layer of C application 
should be written for specific function calls, parameter passing and result 
set accumulation or manipulation. From Scala compiler (and executor) this 
application can be accessed through Native Interfaces (JNA4Scala !!). I am 
going to explore the documentation to see how GC works (important) and how 
DataFrames / DataArrays are stored in cache when called from Scala through 
Native Interfaces (JNA4Scala !). 

Please provide any other important links. 


On Thursday, October 22, 2015 at 12:42:07 PM UTC-7, Spencer Russell wrote:
>
> Julia has a well-developed C API, so you can embed it inside other 
> applications. Info on using it is here:
> http://docs.julialang.org/en/release-0.4/manual/embedding/ 
> 
>
> -s
>
> On Oct 22, 2015, at 3:07 PM, ssarkaray...@gmail.com  wrote:
>
> I found that you are one of the core developers of Julia language. Could 
> you please explain how Julia compiler and executor can be called
> through APIs ?  Are there any documentations for APIs. 
> Is it possible to call Julia compiler and executor through programming 
> interfaces from Scala compiler / executor ?  I am 
> trying to understand broad strategy for possible implementation of 
> ScalaJulia language.
>
> On Wednesday, October 21, 2015 at 12:41:49 PM UTC-7, Stefan Karpinski 
> wrote:
>>
>> 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,  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 
>>>  (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> wrote:

> On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey  
> 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 

Re: [julia-users] Julia and Object-Oriented Programming

[Abe Schneider]

I think this is generally in-line with what I've been advocating for, and 
not that different from Scala's mix-ins:

trait Wheel {
  // ...
}

trait Frame {
  // ...
}

class Unicycle extends trait Wheel, Frame {
   // ...
}

is essentially doing the same thing (i.e. copying the member variables and 
methods over).

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.
>
>
>
>

Re: [julia-users] Julia and Object-Oriented Programming

[Brendan Tracey]

> 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.
>

Yea, it's this kind of thing that makes it tricky in Julia. The obvious 
problem is that you add a method (say cushiness to Frame) which makes 
dispatch ambiguous. One could add higher-level dispatch rules, but that's 
likely to add a lot of complexity.


On Thursday, October 22, 2015 at 7:03:43 AM UTC-6, Abe Schneider wrote:
>
> I think this is generally in-line with what I've been advocating for, and 
> not that different from Scala's mix-ins:
>
> trait Wheel {
>   // ...
> }
>
> trait Frame {
>   // ...
> }
>
> class Unicycle extends trait Wheel, Frame {
>// ...
> }
>
> is essentially doing the same thing (i.e. copying the member variables and 
> methods over).
>
>
I'm not familiar with Scala, so sorry if I'm telling you something you 
know, but in go the member variables and methods are not copied over. The 
Unicycle struct in go does not itself have those fields, the fields of the 
struct do. In other words, defining

type Unicycle struct {
Frame
Wheel
Seat
} 

Is exactly like declaring 

type Unicycle struct {
   Frame Frame
   Wheel Wheel
   SeatSeat
} 

except that in the former case one can call unicycle.Cushiness() , and in 
the latter one must call unicycle.Seat.Cushiness(). In particular, if you 
swap out one Frame in the unicycle for a different Frame, the field values 
change (the methods won't, since methods are with a type).

Re: [julia-users] Julia and Object-Oriented Programming

[ggggg]

What is the other option here? It seemed like with the OO/Julia way you are 
complaining about you at least have working (but slow) code handling your 
new polynomial type. In a case where your new type doesn't work with 
"obtainCoefficient", it won't 
work with any of your other code either. You would just have no working 
code with your new polynomial type. How is that better?

But the next week, someone asks whether you can handle polynomials 
> specified as p(x)=det(A-x*B), where A and B are n-by-n matrices.  For 
> polynomials in this format, "obtainCoefficient" is expensive and would not 
> be regarded as a simple "getter" operation.  If many people had already 
> written functions invoking the 'obtainCoefficient' method, then you would 
> be stuck.  You would retrospectively realize that the obtainCoefficient 
> member function was not a good idea.  This example is typical of open-ended 
> scientific software projects.
>
>>
>>

Re: [julia-users] Julia and Object-Oriented Programming

[Tom Breloff]

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 
wrote:

> On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey 
> 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.
>

Re: [julia-users] Julia and Object-Oriented Programming

[Stefan Karpinski]

On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey 
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.

Re: [julia-users] Julia and Object-Oriented Programming

[Stefan Karpinski]

On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey 
wrote:

> The US Supreme Court may get involved if you call it Scalia. Hard to know
> in which direction.


The watershed Scalia vs. Scalia case of 2016.

Re: [julia-users] Julia and Object-Oriented Programming

[Stefan Karpinski]

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,  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 
>  (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 
>> wrote:
>>
>>> On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey 
>>> 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.
>>>
>>
>>

Re: [julia-users] Julia and Object-Oriented Programming

[ssarkarayushnetdev]

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 
 (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  > wrote:
>
>> On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey > > 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.
>>
>
>

Re: [julia-users] Julia and Object-Oriented Programming

[ssarkarayushnetdev]

Both Scala and Java are object oriented programming languages.  These OOP 
languages were used to build Hadoop Map-Reduce, Spark, Mlib and many
other big data programming / tools framework. Julia should be seamlessly 
integrated with these mainstream big data and machine learning frameworks 
for analyzing large volumes of data in parallel, using Statistics, 
Calculus, Linear algebra and other computing models. Combining Scala and 
Julia 
can be a step towards this direction.


On Wednesday, October 21, 2015 at 12:43:17 PM UTC-7, vav...@uwaterloo.ca 
wrote:
>
> Earlier I posted a statement in this thread that object-oriented 
> programming is in many cases not suitable for scientific software because 
> it forces the designer to make decisions too early in the design process 
> that become unwelcome constraints as the project progresses.  
>
> If I understand what people are saying about traits, they may pose the 
> same danger.  Just to give a simple example, suppose you are designing a 
> class for univariate polynomials over a ring K.  You might expect that you 
> will need both dense and sparse (i.e., most coefficients=0) polynomials, so 
> you might create an abstract class for both dense and sparse polynomials. 
>  In current Julia you might write:
>
> abstract UnivariatePolynomial{T}
>
> where T is the underlying ring.  You would specify nothing else.  Now if 
> 'traits' were available as a language feature, you might create a member 
> function "obtainCoefficient" that would work properly for both sparse and 
> dense polynomials.
>
> But the next week, someone asks whether you can handle polynomials 
> specified as p(x)=det(A-x*B), where A and B are n-by-n matrices.  For 
> polynomials in this format, "obtainCoefficient" is expensive and would not 
> be regarded as a simple "getter" operation.  If many people had already 
> written functions invoking the 'obtainCoefficient' method, then you would 
> be stuck.  You would retrospectively realize that the obtainCoefficient 
> member function was not a good idea.  This example is typical of open-ended 
> scientific software projects.
>
> So again, I would be wary of adding object-oriented features to Julia, at 
> least until the language matures a bit more mature.
>
> I have been on the other side of this fence already: I wrote the code for 
> SortedDict in DataStructures.jl.  I had a mandate from Kevin Squire to make 
> SortedDict a drop-in replacement for Dict.  Since there is no formal 
> interface for 'Dict' defined, and indeed, Julia does not have a  means to 
> specify interfaces, this means that I actually have to read all the code in 
> associative.jl and dict.jl in order to carry out Kevin's mandate.  But this 
> turns out to be not so hard!
>
> -- Steve Vavasis
>
>
>
>
>
>
> On Wednesday, October 21, 2015 at 1:00:25 PM UTC-4, 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  
>> wrote:
>>
>>> On Tue, Oct 20, 2015 at 7:00 PM, Brendan Tracey  
>>> 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 

Re: [julia-users] Julia and Object-Oriented Programming

[Stefan Karpinski]

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.

On Tuesday, October 20, 2015, 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, ssarkaray...@gmail.com
>  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.
>>>
>>>
>>>
>>>

Re: [julia-users] Julia and Object-Oriented Programming

[Brendan Tracey]

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.