Yes, symbols would be preferred. Checking equality two symbols is quicker, but, more importantly, symbols are natural to Julia metaprogramming/expressions, meaning that if you use symbols then the expression is easier to generate via macros.
Tom is getting shy, but really take a look at StochasticOptimization.jl. Yes, it will change, but it does have a very nice design which is extendable and allows for the flexibility and the parameters that you need, and even more. Another good way to accomplish this may be call-overloaded types. IMHO, you may find that trying to fit an OO framework to this might be more work than correctly designing the framework the first time. Of course, YMMV. On Sunday, October 9, 2016 at 1:07:12 PM UTC-7, Bart Janssens wrote: > > 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 <rack...@gmail.com > <javascript:>> 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? >> >>
