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 >
