Re: [julia-users] Re: @test_approx_eq results in stack overflow for custom immutable type

[Jacob Quinn]

I think what would really be helpful here are explicit interfaces. There's
an open issue about it: https://github.com/JuliaLang/julia/issues/6975

In a world with interfaces, you would have been told at some point (either
inheriting from number or calling certain methods), that your type was
missing the Comparable interface. You wouldn't see any stack overflows
because you'd have been stopped before getting to that point.

-Jacob


On Wed, Jul 23, 2014 at 9:11 PM, daniel.m...@gmail.com wrote:

 Wonderful!  Thank you!

 The associated problem here is that the error message didn't really help
 me.  I know the developers are busy, but I hope that there's a way to
 eventually improve the error message for this situation.

 Thanks again.

 Daniel

 On Tuesday, July 22, 2014 9:22:31 PM UTC-5, danie...@gmail.com wrote:

 Inspired by the mighty ModInt example, I tried my hand at making a new
 immutable type.  I wanted to make a FloatingPoint type that won't drift as
 it gets incremented, for use as a time in an integration loop.  I've
 attached my code.

 The short story is: I try to compare the type's value to a Float64
 literal with @test_approx_eq and I get the following error:

 ERROR: stack overflow
  in = at promotion.jl:170 (repeats 8 times)
 while loading 
 /Users/dmatz/Data/Projects/simulations/julia/time/integer_times_test.jl,
 in expression starting on line 28


 If I manually convert my type to Float64, it of course works.  I've
 provided a promote_rule to Float64, which seems to automatically make a lot
 of operators work.  But why does @test_approx_eq not work?  The stack trace
 doesn't really help.  I tried to manually do a =, and that works just
 fine...

 Thanks!

 Daniel

Re: [julia-users] Re: @test_approx_eq results in stack overflow for custom immutable type

[daniel . matz]

While I'm not a programming wizard like so many in this community, I do 
hope that the developers are familiar with the interfaces in Go.  I didn't 
see any mention of Go in that issue, though.

I like how in Julia the types and methods are decoupled, in that the 
methods aren't bound to the type, if I'm saying that correctly.  I find my 
thoughts translating to code more naturally than in C++, where everything 
seems to get coupled together.

The way Go does interfaces is kind of analogous to this.  The interfaces 
are defined, but then the types that implement the interface aren't 
specifically declared as such.  The type just has to provide the required 
methods.  It seems so lightweight and natural.

Whatever you all come up with, I'm sure it will be great, if the rest of 
Julia is any indication.

Daniel