Oop 为什么大多数面向对象语言不支持协同路由？

我现在正在准备考试。我在一次旧考试中发现的一个问题是：
“为什么大多数面向对象语言不支持协同路由？（提示：这不是因为它们支持线程）”

问题是，我找不到一个好答案。当然，如果您有面向对象功能，则不需要协同路由，但在某些情况下，拥有它们仍然非常有用。

这只是一个猜测：

协同程序使用子例程的状态来改变其返回值，而对象上的方法可以使用对象状态来改变其返回值。

这听起来像是一个糟糕的考试问题——它非常主观，没有一个正确的答案，甚至没有最好的答案。长话短说，我认为没有人能做的比猜测更多

我猜，这主要是因为包括了Pascal程序、并发C（实际上支持C++的时间）和艾达任务也有相似性的语言，从来没有特别流行过。从技术角度来看，这些设计已经非常好了，但它们从未变得特别流行。在某种程度上，这和其他任何事情一样可能是一个时间问题。当多处理器计算机成为大多数程序员实现并行计算的真正目标时，这些语言已经基本被遗忘

---

从技术角度来看，我不确定是否有人有很多新的东西要补充——主要需要的是一个好的“推销”来让并发C或Ada 95（等等）听起来像是新的和创新的东西，足以让人们至少尝试一下。当然，几十年前的实现通常是单线程的，这需要更新。然而，举个例子，我确信Ada95的实现已经更新，所以它们可以很好地使用多个核心。不过，这似乎并没有让它流行多少（例如，在这里，

ada

标签目前只被使用了90次）。

我认为这是因为意识形态的原因。在OOP中，表示状态的主实体是对象。其他内容不应具有状态。在协同程序的世界中，它们又成为了一个状态的载体，这与OOP略有矛盾。在C#中有次要版本的协同程序：yield语句，但它纯粹是C#的特性，而不是CLR和.net本身，而编译后的所有状态变量都成为隐藏类的字段。这是因为在.net中，除了object之外，没有任何东西可以有状态。

在考试中，这样的问题的目的不是看你是否知道答案。（不需要有正确的答案）而是要确定学生是否在学科领域内发展了思考和推理的能力

如果我要回答这个问题，我会观察到：a）参与者模型在很大程度上是面向对象与协同程序的结合，从这个意义上讲，参与者（代理）可以同时接收和处理消息。b） 在OOP语言中不经常使用协同路由的真正原因与在任何主流语言中不经常使用协同路由的原因相同，即。在传统堆栈的存在下，协同路由很难实现

---

我的反应几乎肯定是为了帮助原创海报。我想我还是会回应的，因为协程和其他形式的并发是当前流行的话题。

对象的思想是隔离状态。你所需要的一切都应该出现在那个物体里。协同程序将“打破”这个想法，因为现在一个对象不再是孤立状态，而是依赖于另一个对象

事实上，Simula 67和Smalltalk 80这两种最终的面向对象语言都完美地支持协同程序。因此，我怀疑协同程序的思想从根本上与OOP本身是不相容的。这更可能是巧合，类似于“为什么主流语言/操作系统中不支持酷炫的东西X”之类的问题。

当然，如果你有面向对象的功能，你不需要协同程序。错。对象只是将数据与功能捆绑在一起……除非协同程序本身是一个对象。