Yea, thats a good point. Granted for my purpose I'm never going to be redefining these types mid program. I suppose one might extend your @unpack to work on an expression and do the substitution recursively like my thing does, then you could write,
@unpack aa: a function(x,aa:A) sin(2pi/a*x) a = 3 #can also assign without repacking end which seems slightly less hacky than what I'm doing but serves a similar purpose. Marius On Fri, Jul 22, 2016 at 9:01 AM, Mauro <[email protected]> wrote: > > On Fri, 2016-07-22 at 01:02, Marius Millea <[email protected]> wrote: > >> FYI Mauro's package has something similar > >> <http://parametersjl.readthedocs.io/en/latest/manual/>. > >> > > > > Some interesting stuff in there, thanks! > > The problem with your `@self` and with Parameters.jl's > `@unpack_SomeType` macros is that it is easy to introduce bugs. > Consider: > > type A # and register it with @self > a > end > @self f(x,aa:A) = sin(2pi/a*x) > > Sometime later you refactor type A: > > type A > a > pi > end > > now your function f is broken. So, for every change in type A you need > to check all functions which use `@self`. > > Instead I now use the @unpack macro (and its companion @pack), also part > of Paramters.jl. Then above f becomes > > function f(x,aa::A) > @unpack aa: a > sin(2pi/a*x) > end > > This is still much more compact than writing out all the aa.a, etc. (if > there are lots of field accesses) but safe. Also, it clearly states, at > the top of the function, which fields of a type are actually used. >
