Name of type and module clash

Hello,

I need to write models according to a predefined template, and it contains a type called Parameters. I cannot really rename it as an entire computing platform (for many models) relies on this particular name. Now I’d like to use the DifferentialEquations package to solve ODEs for this model. Unfortunately, the module Parameters is used within this package (and despite that it is being used inside the module DifferentialEquations, its name is added to the names of the workspace…), and I cannot define my type Parameters subsequently. Following is the problematic code:

using DifferentialEquations
type Parameters
    p
end

I would have liked to remove the symbol :Parameters before defining my type Parameters from the workspace but as I understand this is not possible.

Is there anything I can do to solve this problem?

Many thanks,

Can you encapsulate it into a module:

julia> module Foo
           struct Parameters # parameters
               p
           end
           function bar(t,x,pars) # rhs of ode 
               dx = similar(x)
               dx[1] = x[1] + pars.p
               dx
           end
       end
Foo

julia> using DifferentialEquations # still use differential equations functionality: 

julia> f = ParameterizedFunction(Foo.bar,Foo.Parameters(1))
(::ParameterizedFunction) (generic function with 2 methods)

julia> f(0,[1])
1-element Array{Int64,1}:
 2

Thanks for your reply.

Unfortunately not, I really need my Parameters to be a type in the main scope. I was wondering if I could prevent Julia to load the name of the module Parameters in names(Main).

I must mention that my Parameters has nothing to do with differential equations.

This issue is fixed in Julia 0.7. In the meantime, I don’t know any solution, but maybe macros can help? Eg. @withparam begin ... end could convert all instances of Parameters into SomeModule.Parameters.

Thanks for the github ref, this is exactly the issue addressing my problem. I’ll probably wait until 0.7 is out to use this procedure, and I’ll rely on alternative ways to solve the ODEs for now.