什么时候（如果曾经）不是邪恶的？

Question

我听说过很多 地方，PHP的eval功能通常不能解决问题。根据PHP 5.3的LSB和闭包，我们没有理由依赖eval或create_function。有没有可能eval在PHP 5.3中有最佳（唯一？）答案的情况？这个问题不是关于eval邪恶是否普遍存在，因为显然不是。答案摘要：评估数值表达式（或PHP的其他“安全”子集）单元测试交互式PHP“外壳”可信赖的反序列化 var_export一些模板语言为管理员和/或黑客创建后门与<PHP 5.3的兼容性检查语法（可能不安全）

Answer 1

主要的问题eval是它是恶意代码的网关。因此，永远不要在可以从外部利用它的环境中使用它，例如用户提供的输入。

一个有效的UseCase将在Mocking Frameworks中。

来自的例子 PHPUnit_Framework_TestCase::getMock()

// ... some code before

    $mock = PHPUnit_Framework_MockObject_Generator::generate(

      $originalClassName,

      $methods,

      $mockClassName,

      $callOriginalClone,

      $callAutoload

    );

    if (!class_exists($mock['mockClassName'], FALSE)) {

        eval($mock['code']);

    }

// ... some code after

实际上，generate方法中发生了很多事情。用外行术语来说：PHPUnit将使用参数generate并从中创建一个类模板。然后eval它将使用该类模板使其可用于实例化。这样做的重点是让TestDoubles当然可以模拟UnitTests中的依赖项。

Answer 2

您可以使用eval创建临时类：

function myAutoLoad($sClassName){

   # classic part

   if (file_exists($sClassName.'.php'){

      require $sClassName.'.php';

    } else {

      eval("

            class $sClassName{

                public function __call($sMethod,$aArgs){

                     return 'No such class: ' . $sClassName;

                 }

                }");

    }

} 

尽管当然使用非常有限（某些API或DI容器，测试框架，必须处理具有动态结构的数据库的ORM，代码游乐场）