'Оценка', как предполагается, противна?

eval не только небезопасен (как уже указывалось в другом месте), он также медленный. Каждый раз, когда он выполняется, AST кода eval необходимо заново анализировать (и, например, для JRuby, превращенного в байт-код), что является строковой операцией и, вероятно, также плохо для локальности кэша (в предположении что работающей программы не много eval, и соответствующие части интерпретатора, таким образом, кешируются, помимо того, что они большие).

Почему в Ruby вообще есть eval, спросите вы? В основном «потому что мы можем» - фактически, когда было изобретено eval (для языка программирования LISP), это было в основном для шоу ! Более того, использование eval - это правильная вещь, когда вы хотите «добавить интерпретатор в ваш интерпретатор» для таких задач метапрограммирования, как написание препроцессора, отладчика или шаблонизатора. Общая идея для таких приложений состоит в том, чтобы помассировать некоторый код Ruby и вызвать eval для него, и это, безусловно, лучше, чем переосмысление и реализация предметно-ориентированного игрушечного языка, ловушка, также известная как Десятое правило Гринспуна . Предостережения: остерегайтесь затрат, например, для движка шаблонов, делайте все свои работы во время запуска, а не во время работы; и не eval не доверяйте коду, если вы не знаете, как его «приручить», то есть выберите и примените безопасное подмножество языка в соответствии с теорией дисциплины способностей . Последний - это много действительно трудной работы (см., Например, , как это было сделано для Java ; я не знаю о таких усилиях для Ruby, к сожалению).

В Ruby есть несколько уловок, которые могут быть более подходящими, чем eval():

1. Существует #send, который позволяет вам вызывать метод, имя которого у вас есть в виде строки, и передавать параметры в она.
2. yield позволяет передавать блок кода методу, который будет выполняться в контексте метода получения.
3. Часто простого Kernel.const_get("String") достаточно, чтобы получить класс, имя которого у вас есть в виде строки.

Я думаю, что я не могу объяснить их должным образом подробно, поэтому я просто дал вам подсказки, если вы заинтересованы, вы будете Google.

Это затрудняет отладку. Это затрудняет оптимизацию. Но, прежде всего, обычно это признак того, что есть лучший способ сделать то, что вы пытаетесь сделать.

Если вы расскажете нам, чего вы пытаетесь достичь с помощью eval, вы можете получить более релевантные ответы, относящиеся к вашему конкретному сценарию.

Оценка является невероятно мощной функцией, которая должна быть использована тщательно. Помимо проблем безопасности, на которые указывает Матовый J, Вы также найдете, что отладка оцененного кода времени выполнения является чрезвычайно трудной. Проблема в оцененном блоке кода времени выполнения будет трудной для интерпретатора выразить - настолько ищущий, это будет трудно.

Однако если Вы довольны той проблемой и не обеспокоены проблемой безопасности, тогда Вы не должны избегать использования одной из функций, которая делает рубин как обращающийся как есть

В определенных ситуациях удачное расположение eval является умным и уменьшает количество требуемого кода. В дополнение к проблемам безопасности, которые были упомянуты Мэттом J, вам также нужно задать себе один очень простой вопрос:

Когда все это сказано и сделано, может ли кто-нибудь еще прочесть ваш код и понять, что вы сделали?

Если ответ отрицательный, то то, что вы получили с eval, забывается для удобства обслуживания. Эта проблема не только применима, если вы работаете в команде, но также применима и к вам - вы хотите иметь возможность оглянуться назад на свои месяцы кода, если не годы, и знать, что вы сделали.

Если вы передаете что-либо, что вы получаете «извне», eval, вы делаете что-то не так, и это очень неприятно. очень трудно избежать кода, достаточного для того, чтобы он был безопасным, поэтому я считаю его довольно небезопасным. Тем не менее, если вы используете eval для избежания дублирования или других подобных вещей, как в следующем примере кода, можно использовать его.

class Foo
  def self.define_getters(*symbols)
    symbols.each do |symbol|
      eval "def #{symbol}; @#{symbol}; end"
    end
  end

  define_getters :foo, :bar, :baz
end

Однако, по крайней мере в Ruby 1.9.1, в Ruby есть действительно мощные методы метапрограммирования, и вы могли бы вместо этого сделать следующее:

class Foo
  def self.define_getters(*symbols)
    symbols.each do |symbol|
      define_method(symbol) { instance_variable_get(symbol) }
    end
  end

  define_getters :foo, :bar, :baz
end

Для большинства целей вы хотите использовать эти методы, и не нужно убегать.

Другая плохая вещь в eval заключается в том, что (по крайней мере, в Ruby) он довольно медленный, поскольку интерпретатору необходимо проанализировать строку и затем выполнить код внутри текущей привязки. Другие методы вызывают функцию C напрямую, и поэтому вы должны получить значительное ускорение.