-1

I have some old code that looks like:

some_variable = "-> (params) { Company.search_by_params(params) }"
if eval(some_variable).is_a?(Proc)
...

Rubocop is complaining about the use of eval. Any ideas on how to remove the usage of eval?

I don't really understand Procs so any guidance on that would be appreciated.

kaimcg
  • 156
  • 1
  • 8
  • 4
    Why do you need to have a variable like that in the first place? Where is the string coming from? Why does it need to be a string? This sounds like a [xy problem](https://meta.stackexchange.com/a/66378/284887) to me. – spickermann Apr 08 '20 at 18:29
  • Here's some overview on blocks and procs: https://stackoverflow.com/questions/3560571/blocks-procs-in-ruby : "Procs and blocks let you pass around _actions_ like you can with _data_"... Which I think is your intent here, right? – Garrett Motzner Apr 08 '20 at 19:34
  • It was code that was written years ago so not sure why they chose to put it in a string, but looks like removing the quotes works. :+1: – kaimcg Apr 08 '20 at 20:20
  • I would try to figure out the intent if possible, because this is worrisome code. – Garrett Motzner Apr 08 '20 at 20:35
  • What part of the code base is this in? Model, controller, migration, etc? – Garrett Motzner Apr 08 '20 at 20:39
  • It was in a controller, a "search_controller" at that. Left in a dark corner of an old and complex codebase that hasn't been changed in a while. The use of eval for so long does sound pretty worrisome. – kaimcg Apr 08 '20 at 20:51

2 Answers2

2

Simple. Don't define your variable object as a string but as a lambda Proc

my_lamda = -> (params) { Company.search_by_params(params) }
if my_lambda.is_a?(Proc)
  #do stuff
end

But why would you instantiate a string object which contains what appears to be a normal lambda which is a Proc, when you can define a Proc instead?

lacostenycoder
  • 10,623
  • 4
  • 31
  • 48
1

I am going to answer the question "If I want to run code at a later time, What is the difference between using a proc and a eval'd string?" (which I think is part of your question and confusion):

What eval does is take a string and parses it to code, and then runs it. This string can come from anywhere, including user input. But eval is very unsafe and problematic, especially when used with raw user input.

The problems with eval are usually:

  • There is almost always a better way to do it
  • Very dangerous and insecure
  • Makes debugging difficult
  • Slow

Using eval allows full control of the ruby process, and if you have high permissions given to the ruby process, potentially even root acmes to the machine. So the general recommendation is use 'eval' only if you absolutely have no other options, and especially not with user input.

Procs/lambdas/blocks also let you save code for later, (and solve most of the problems with eval, they are the "better way") but instead of storing arbitrary code as a string to read later, they are code already, already parsed and ready to go. In someways, they are methods you can pass around later. Making a proc/lambda gives you an object with a #call method. Then when you later want to run the proc/block/lambda, you call call([arguments...]). What you can't do with procs though is let users write arbitrary code (and generally that's good). You have to write the code for the proc in a file ruby loads (most of the time). Eval does get around that, but you really should rethink if you really want that to be possible.

Your code sample oddly combines both these methods: it evaluates a string to a lambda. So what's happening here is eval is running the code in the string right away and returning the (last) result, which in this case happens to be a lambda/proc. (Note that this would happen every time you ran eval, which would result in multiple copies of the proc, with different identities, but the same behavior). Since the code inside the string happens to make a lambda, the value returned is a Proc which can later be #call'd. So when eval is run, the code is parsed, and a new lambda is created, with the code in the lambda stored to be run at a later time. If the code inside the string did not create a lambda, the all that code would be run immediately when eval was called with the string.

This behavior might be desired, but there is probably a better way to do this, and this is definitely a foot-gun: there are at least a half dozen subtle ways this code could do unintended things if you weren't really careful with it.

Garrett Motzner
  • 3,021
  • 1
  • 13
  • 30