I think it's not. As Steven alluded to, eval shouldn't be used that often. Since you could have written separate if-statement checks that would do what you wanted, all the info needed was there at compile time, and the macro just helps shorten it up. And it's not good practice to use run-time code generation to do something available at compile-time.
That said, it is a bit odd you can't access keyword arguments just with their symbol, but I suppose that is the tradeoff in making them much more dynamic. I presume you also know about passing them using the varargs... form, where you *can* check by symbol, though without having defaults... On Tuesday, February 10, 2015 at 7:38:42 AM UTC-5, Dominique Orban wrote: > > Josh, > > Many thanks! That works very well. I'm quite bummed as to why the > symbol-based approach isn't working (or the syntax for it is to elusive). > It seemed that iterating over variables using symbols would be the thing to > do, but maybe not. > > Cheers! > > On Monday, February 9, 2015 at 3:27:46 PM UTC-5, Josh Langsfeld wrote: >> >> Here's a macro that just has the effect of combining the code that would >> check each variable's length into a short form. It refers to the input >> variables both by name and value. >> >> macro lencheck(l,vars...) >> exprs = Expr[] >> for v in vars >> sym = string(v) >> push!(exprs,:(if length($v) != $l error(string($sym," must be >> length ",$l)) end)) >> end >> Expr(:block, exprs...) >> end >> >> >> Invoke with: @lencheck 5 x y z #etc... >> >> On Monday, February 9, 2015 at 1:06:25 AM UTC-5, Dominique Orban wrote: >>> >>> That's what I used to do, but because there will be several such >>> optional args, I need to be able to tell which doesn't have the right size. >> >>
