Working on something else in Archaeopteryx, I realized this was hard to read, so I moved it around a little.
At that point it occurred to me I might be able to make it into a method call. And it's true, you can - sort of.
But it's kinda ugly. My goal in the refactor had been to make the code easier to read - but I don't think that
&L{method_call} is easy to read. Arx aliases lambda to L so the way you'd normally see that (if anybody normally used it) would be &(lambda{method_call}).The parentheses seem to make things better.
The tradeoff: more Lispy, less Perlish.
I think on the whole this refactor improves things but it's hard to say for sure. The code is unusual enough that I don't even know any guidelines or rules of thumb for a situation like this. Honestly, the difference between an instance variable
lambda and a def method_name is almost entirely a matter of syntax sugar anyway. Sometimes I think Ruby is just a language for people who want to write Lisp they can share with non-Lispers.
Neat stuff. One teeny-weeny note: you can replace (0..(@beats - 1)) with (0...@beats).
ReplyDeleteCheers!
Anon - yeah but I hate remembering that kind of thing, so I just decided years ago to only ever use ..
ReplyDeleteBut you're right.
Another teeny note, since eval is evil, try:
ReplyDeleteinstance_variable_set("@#{option}", attributes[option.to_sym])
Dude, you're insane. eval is awesome. Avoiding eval without a good reason is superstitious. Next should I throw salt over my shoulder to ward off eval spirits?
ReplyDeleteI guess my reason is that code should be code, not strings. It looks ugly - I think my version reads better..."What is happening here? Oh, an instance variable is being set". I just wish instance_variable_set didn't require the '@' prefix.
ReplyDeleteNo good reason, just aesthetics.
No, I very firmly disagree. You shouldn't write code if you don't have to. That's what computers are for. This is an important principle.
ReplyDelete