OK, thanks, so symbols are definitely preferred for the [] variant then? As for using dispatch, I am certainly all for designing a "proper" Julian interface, but the number of parameters here can be daunting, see e.g. here for a more complete example: https://github.com/barche/coolfluid3/blob/master/doc/tutorials/live_visualization/cylinder.py#L45-L57
This is indeed from an object-oriented C++ framework, where we have a tree of objects that each have options controlling their behavior. In the non too distant future I would like for it to be possible to extend this using models written in Julia (because they can be as fast as C++, but with a lot less headaches for students I hope), but rewriting the entire framework is just too much work right now, so I think we are stuck with this overall structure for the time being. On Sun, Oct 9, 2016 at 9:13 PM Chris Rackauckas <rackd...@gmail.com> wrote: > Missed that one, though it should be > > mysolver[:linear_system][:parameters][:solver_type] = :GMRES > > There's no reason for an algorithm choice to be a String. > > But this entire thing seems wrong-headed. The choice of the solver method > should likely be done by dispatching on the solve method somehow. This > seems like trying directly match an object-oriented framework which > shouldn't be recommended (look at how fast it gets messy). You may want to > see if you can map a framework like StochasticOptimization.jl > <https://github.com/JuliaML/StochasticOptimization.jl> to > IterativeSolvers.jl <https://github.com/JuliaMath/IterativeSolvers.jl>. > > > On Sunday, October 9, 2016 at 11:34:46 AM UTC-7, Kristoffer Carlsson wrote: > > That was one of the suggestions? > >
