如何评价PHP的FierRFC？

我在之前一篇回答中传送门，有人对我的回答中做了回复，大概意思是说Fier的描述来看和yield很像。

在我多年的开发经验中，深入研究yield和Fier后，发现它们之间存在着显著的差异。

首先，yield这个特性较特，它并不具备自身专有的栈空间。当我们使用yield函数时，作为开发者，面临着两种处理方式。一方面，我们可以使用foreach循环对其进行迭代处理；另一方面，也可以借助yieldfrom作符，将这个迭代器传递给调用者，让调用者来完成迭代作。然而，这种机制在实际开发中会给我们带来一些不便之处。当我们调用一个函数时，必须要明确知晓该函数是否为yield函数。如果是yield函数，就需要我们对其进行额外的处理，要么我们自己编写代码对其进行迭代，要么将迭代的工作转交给外层调用者。在涉及到深度函数调用的情况下，这种处理方式无疑会给我们增加不少负担，开发过程会变得更加繁琐。从某种程度上，这与JaScript中的await有些许相似之处，但又不完全相同。

与之相，Fier则具有自己的调用栈。值得注意的是，Fier通常具有约1M的栈开销，这在使用时是需要我们重点考虑的一个因素。它可以在函数调用的任意深度位置使用Fier::suspend()来暂停执行，而恢复执行的作只需要在最外层Fierstart的作用域内进行处理即可。更重要的是，在嵌套调用的过程中，对于那些调用函数的开发者而言，无需关心被调用的函数内部是否使用了Fier::suspend()。因为一旦使用了Fier::suspend()，整个调用栈都会停止，CPU的执行流程会自动回到Fierstart或者Fierresume的位置。无论函数调用的深度是五层还是十层，开发者都无需为此心，它可以像一个普通的同步函数调用一样作，内部的细节被很好地隐起来，这对于开发者来说，无疑是更为友好和便捷的开发体验，极大地简化了开发过程中的复杂性和认知负担，让我们能够更加专注于业务逻辑的实现，而不必陷入繁琐的底层细节处理之中。

作为开发人员，在不同的场景下，我们需要根据具体的需求来选择使用yield还是Fier。对于简单的迭代任务，yield或许可以满足需求，但在处理复杂的并发和异步作时，Fier凭借其特的特性，为我们提供了更强大的功能和更简洁的开发模式，让我们能够更高效地实现复杂的程序逻辑，避免陷入不必要的开发困境。这也是我们在开发过程中，需要不断权衡和选择的重要方面，根据项目的实际情况，合理运用这些特性，才能编写出高质量、高性能的代码。

在使用yield时，我们需要时刻关注迭代的处理方式，因为其简单的实现机制虽然节省了栈空间，但在复杂的嵌套调用场景下会让开发者感到困扰。而Fier的出现，为我们解决了这一问题，其的调用栈和简洁的暂停恢复机制，是它在处理复杂任务时展现出的强大优势，使我们能够轻松驾驭深度嵌套和并发作，为我们在并发编程的海洋中提供了更加稳健的航行工具。这也反映了不同语言特性的设计初衷，旨在为我们提供多样化的工具，以应对各种复杂的开发需求。

不过，需要注意的是，在使用Fier时，虽然它带来了诸多便利，但也要考虑到其可能存在的性能开销，特别是在大规模使用的情况下，其栈空间可能会消耗较多的内存资源，这就需要我们在开发时进行仔细的权衡和资源规划。总之，在软件开发的世界里，我们要充分理解各种工具的特性，发挥它们的优势，规避它们的劣势，以达到最优的开发效果。

总之，作为开发者，我们应当根据具体的开发场景和性能需求，灵活运用这些特性，同时，也要时刻关注代码的可性和性能优化，以确保我们的代码在满足功能需求的同时，能够高效稳定地运行。这需要我们不断积累经验，在实践中不断探索和总结，才能在不同的开发场景下做出最恰当的选择。