That's an option for immutable types and it amounts to making the types of fields implicit (invisible) type parameters. For mutable types, the type of an abstractly typed field can change at any point in time, so that's not an option.
On Wed, Oct 22, 2014 at 12:08 PM, Cedric St-Jean <cedric.stjean...@gmail.com > wrote: > Somewhat OT: since the JIT compiles a different function for each argument > type combination, couldn't it compile a different type object for every > field type combination? > > > On Wednesday, October 22, 2014 10:53:26 AM UTC-4, Iain Dunning wrote: >> >> Do you feel like you are over-typing things? >> >> In function definitions, you only need types if you actually need to them >> to pick a function to dispatch to. They don't make anything go faster, as a >> specific version of a function will be compiled for every different set of >> argument types you try calling it with. >> >> So, check out: >> https://github.com/IainNZ/GraphLayout.jl/blob/master/src/spring.jl >> for example. >> layout_spring_adj{T}(adj_matrix::Array{T,2} >> So it takes any array of element type T. For every time you call this >> with a different element type, a different version of the function will be >> compiled. So this fancy looking code: >> if adj_matrix[i,j] != zero(eltype(adj_matrix)) >> Simply gets turned into if adj_matrix[i,j] != 0.0 or 0 or False or .... >> and so on, pretty magic! >> >> For Types, you should specify concrete types whenever you can, or use >> parametric types if you can't. If you don't, and use say, Number, or leave >> it blank, simple things like Float64s and Ints will be "boxed", so there >> will be overhead whenever you use them and the compiler may struggle to >> infer that some things are Float64s or Ints and not just Anys. >> >> Hope that helps somewhat. >> >> On Wednesday, October 22, 2014 7:28:12 AM UTC-4, Nils Gudat wrote: >>> >>> Hi Andreas, >>> >>> Don't know if you've seen this already and whether this is helpful at >>> all, but I discovered this site >>> <http://sidekick.windforwings.com/2013/03/print-julia-type-tree-with-juliatypesjl.html> >>> once when I got confused by some TypeErrors, it basically lays out the >>> entire type tree of Julia. >>> >>> Best, >>> Nils >>> >>> On Wednesday, October 22, 2014 12:11:03 PM UTC+1, Andreas Lobinger wrote: >>>> >>>> Hello, >>>> >>>> i'm now a julia user for some time, but still i have problems (comming >>>> from a c, f77, matlab, python background) to understand the type system. >>>> Especially when i try to integrate own code into packages (happened to >>>> Cairo + Compose, pending for Winston) i seem to choose always a more >>>> complicated way (my observation, code similar in py or c just looks >>>> shorter...) because somehow things do not match. >>>> >>>> So. >>>> >>>> What to read to understand the julia approach to types and type >>>> interference? >>>> >>>> Wishing a happy day, >>>> Andreas >>>> >>>> >>>>
