Andrew, I found your suggestion very helpful. However, it seems complicated to place uninitialized fields last. Why is this? The field have names and when calling *new() *you are using these names.
For example: *julia> type foo* * a :: Int64* * b :: Int64* * function foo()* * b=3* * return new(b)* * end* * end* *julia> var = foo()* *foo(3,0)* *julia> xdump(var)* *foo * * a: Int64 3* * b: Int64 0* Even if I ask b to be initialized, a is initialized instead. Why is this? On Sunday, April 20, 2014 at 10:51:29 AM UTC-4, andrew cooke wrote: > > yes, you can do this. just place those fields last and use an internal > constructor to define everything else. > > its described at > http://julia.readthedocs.org/en/latest/manual/constructors/#incomplete-initialization > > (types are so important in julia that the info is in several chapters - you > need to read the types and the constructors chapters to get a good > understanding). > > andrew > > > On Saturday, 19 April 2014 21:50:05 UTC-3, Spencer Lyon wrote: > >> Say I have a type that defines a model. Something like this: >> >> abstract Model >> >> type Results >> # Details not shown here >> end >> >> type IFP{T <: FloatingPoint} <: Model >> # Model parameters >> rho::T >> beta::T >> r::T >> R::T >> gamma::T >> >> # Grid parameters for a >> n_a::Integer >> a_max::T >> a::Vector{T} >> >> # Parameters for y >> n_y::Integer >> y::Vector{T} >> P::Matrix{T} >> >> Sol::Results >> >> end >> >> I would like to be able to initialize an object of type IFP, work with it >> for a while, pass it to a solution routine, and then fill in the Sol >> field at a later time. >> >> Is there a way to leave Sol as an uninitialized field and then fill it >> in after the solution has been determined (which will be after constructing >> the IFP object and playing around with it for a while)? I suppose one >> way would be to have the inner constructor directly call the solution >> routine to get the Sol object. However, I want to avoid that because I >> may want to manipulate IFP between its construction and actually solving >> the model it describes. >> ------------------------------ >> >> One more note. In this specific use case Sol could effectively be >> replaced by two other fields: >> >> c::Matrix{T} >> ap::Matrix{T} >> >> Would that be an easier way to work with them as uninitialized fields? If >> so, why? >> >
