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 Stochas
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/mast
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.
That was one of the suggestions?
Why not use Symbols instead of strings here?
On Sunday, October 9, 2016 at 8:26:57 AM UTC-7, Bart Janssens wrote:
>
> Hi all,
>
> I'm thinking about how to translate a Python interface that makes
> extensive use of __getattr__ and __setattr__ overloading to allow chaining
> a series of option va
What about nested modules?
Or unpure functions chained with the pipe operator?
On Sunday, October 9, 2016 at 11:26:57 AM UTC-4, Bart Janssens wrote:
>
> Hi all,
>
> I'm thinking about how to translate a Python interface that makes
> extensive use of __getattr__ and __setattr__ overloading to al
