Re: [julia-users] Re: Setting/getting field-like members with side effects

[Chris Rackauckas]

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  > 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 
>>  to 
>> IterativeSolvers.jl .
>>
>>
>> On Sunday, October 9, 2016 at 11:34:46 AM UTC-7, Kristoffer Carlsson 
>> wrote:
>>>
>>> That was one of the suggestions? 
>>
>>

Re: [julia-users] Re: Setting/getting field-like members with side effects

[Bart Janssens]

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  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
>  to
> IterativeSolvers.jl .
>
>
> On Sunday, October 9, 2016 at 11:34:46 AM UTC-7, Kristoffer Carlsson wrote:
>
> That was one of the suggestions?
>
>

[julia-users] Re: Setting/getting field-like members with side effects

[Chris Rackauckas]

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 
 to 
IterativeSolvers.jl .

On Sunday, October 9, 2016 at 11:34:46 AM UTC-7, Kristoffer Carlsson wrote:
>
> That was one of the suggestions? 

[julia-users] Re: Setting/getting field-like members with side effects

[Kristoffer Carlsson]

That was one of the suggestions? 

[julia-users] Re: Setting/getting field-like members with side effects

[Chris Rackauckas]

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 values like this example:
> mysolver.linear_system.parameters.solver_type = "GMRES"
>
> Each time a . is encountered, the appropriate __getattr__ is called, which 
> in turn calls a C++ function to get the correct value, which may not be 
> stored as a true data field member anywhere. In the end, the assignment 
> triggers a call to __setattr__ and may call additional functions to notify 
> functions of the change. I see 3 ways of tackling this in Julia:
>
> 1. Just use methods to get/set each field, so something like:
> setproperty(getproperty(getproperty(mysolver, "linear_system"), 
> "parameters"), "solver_type", "GMRES")
> As is obvious from the example, this is a bit cumbersome and hard to read 
> with a long chain of gets.
>
> 2. Use the [] operator, which can be overloaded, as far as I understand. 
> The question there is if we use strings or symbols as keys, to get either:
> mysolver["linear_system"]["parameters"]["solver_type"] = "GMRES"
> or:
> mysolver[:linear_system][:parameters][:solver_type] = "GMRES"
> Either solution is still not as readable or easy to type as the Python 
> original
>
> 3. Finally use a macro, such as enabled by the DotOverload.jl package (
> https://github.com/sneusse/DotOverload.jl):
> @dotted mysolver.linear_system.parameters.solver_type = "GMRES"
>
> I realise this touches on the discussion on . overloading at 
> https://github.com/JuliaLang/julia/issues/1974 but that seems to have 
> dried out a bit, and I understand that touching an operation that is 
> expected to have (almost?) no inherent cost such as field access may be 
> dangerous. The macro solution in 3 seems like the most elegant method, but 
> I worry about code readability, since the purpose of the @dotted will not 
> be immediately clear to people unfamiliar with the DotOverload package. 
> Could a macro like this be provided in Base, with proper documentation 
> (near the descriptions of types and their fields, for example), so option 3 
> can be used without concerns over code readability/understandability?
>
> Cheers,
>
> Bart
>

[julia-users] Re: Setting/getting field-like members with side effects

[dnm]

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 allow chaining 
> a series of option values like this example:
> mysolver.linear_system.parameters.solver_type = "GMRES"
>
> Each time a . is encountered, the appropriate __getattr__ is called, which 
> in turn calls a C++ function to get the correct value, which may not be 
> stored as a true data field member anywhere. In the end, the assignment 
> triggers a call to __setattr__ and may call additional functions to notify 
> functions of the change. I see 3 ways of tackling this in Julia:
>
> 1. Just use methods to get/set each field, so something like:
> setproperty(getproperty(getproperty(mysolver, "linear_system"), 
> "parameters"), "solver_type", "GMRES")
> As is obvious from the example, this is a bit cumbersome and hard to read 
> with a long chain of gets.
>
> 2. Use the [] operator, which can be overloaded, as far as I understand. 
> The question there is if we use strings or symbols as keys, to get either:
> mysolver["linear_system"]["parameters"]["solver_type"] = "GMRES"
> or:
> mysolver[:linear_system][:parameters][:solver_type] = "GMRES"
> Either solution is still not as readable or easy to type as the Python 
> original
>
> 3. Finally use a macro, such as enabled by the DotOverload.jl package (
> https://github.com/sneusse/DotOverload.jl):
> @dotted mysolver.linear_system.parameters.solver_type = "GMRES"
>
> I realise this touches on the discussion on . overloading at 
> https://github.com/JuliaLang/julia/issues/1974 but that seems to have 
> dried out a bit, and I understand that touching an operation that is 
> expected to have (almost?) no inherent cost such as field access may be 
> dangerous. The macro solution in 3 seems like the most elegant method, but 
> I worry about code readability, since the purpose of the @dotted will not 
> be immediately clear to people unfamiliar with the DotOverload package. 
> Could a macro like this be provided in Base, with proper documentation 
> (near the descriptions of types and their fields, for example), so option 3 
> can be used without concerns over code readability/understandability?
>
> Cheers,
>
> Bart
>