If I don't want to leave fields uninitialized what is the easiest and most correct way to initialize them? Put them all zero with an inner constructor?
Thanks a lot, Alex On Thursday, May 7, 2015 at 12:56:35 PM UTC-4, Alexandros Fakos wrote: > > 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? >>> >>
