4 ms·
If using meta-programming to get "basic" features rubs you the wrong way, the language might just not be for you. In general, the Julia philosophy (as well as t
by mindB 7y ago
If using meta-programming to get "basic" features rubs you the wrong way, the language might just not be for you. In general, the Julia philosophy (as well as the lisp philosophy from which Julia descends) is that things which can be done efficiently using macros instead of being built-in should be done with macros. Language features are only for things that cannot be accomplished via metaprogramming. As far as actual implementations of method-forwarding macros, there's an implementation in Lazy.jl[1], and TypedDelegation.jl[2].
[1] https://github.com/MikeInnes/Lazy.jl/blob/0de1643f37555396d615e825fb17b73edb0b5939/src/macros.jl#L275 https://github.com/MikeInnes/Lazy.jl/blob/0de1643f37555396d6...
[2] https://github.com/JeffreySarnoff/TypedDelegation.jl https://github.com/JeffreySarnoff/TypedDelegation.jl
- oxinabox 7y agoI have concluded that it is basically impossible to write a general purpose delegation macro. I have seen many and alway immediately run into cases they can't handle. A top level `for m in (:foo, :bar); @eval $m(X::MyType) = $m(X.backing)` Is general and has no performance overhead
- mindB 7y agoTo be honest, I've never found the need for delegating a huge number of methods in my own work, but then I've never wanted to add a feature or field to something as complex and featureful as e.g. a DataFrame. What issues have you run into when using method-forwarding/delegation macros? The nice thing about the Julia ecosystem is that people tend to be pretty willing to step back and define their methods in terms of an interface (Tables.jl in this case) which then allows code reuse without brittle delegation. Having to put so much effort into changing the structure of upstream doesn't seem ideal from a composability perspective though.