Почему большинство объектно-ориентированных языков не поддерживают сопрограммы?

Question

Я сейчас готовлюсь к экзамену.Один из вопросов, который я нашел на старом экзамене: "Почему большинство объектно-ориентированных языков не поддерживают сопрограммы? (Совет: это не потому, что они поддерживают потоки)" Проблема в том, что я не могу найти хороший ответ.Конечно, вам не нужны сопрограммы, если у вас есть объектная ориентация, но было бы очень полезно иметь их в некоторых случаях.

Answer 1

Я думаю, что это из-за идеологических причин.В ООП основной сущностью, которая представляет состояние , является объект.Ничто другое не должно иметь состояние .В мире сопрограмм они становятся еще одним носителем государства, что немного противоречит ООП.В C # есть второстепенная версия оператора сопрограммы: yield, но это чисто особенность C #, а не CLR и самого .net, в то время как все скомпилированные переменные состояния становятся полями скрытого класса.Это потому, что ничто, кроме объекта, не может иметь состояние в .net.

Answer 2

Цель такого вопроса на экзамене - не узнать, знаете ли вы ответ. (Правильный ответ не обязательно должен быть.) Скорее, это означает, развил ли ученик способность мыслить и рассуждать в предметной области.

Если бы я былЧтобы ответить на этот вопрос, я бы заметил: а) модель актора - это в значительной степени слияние объектной ориентации с сопрограммами, в том смысле, что актеры (агенты) могут получать и обрабатывать сообщения одновременно.б) Реальная причина, по которой сопрограммы не часто встречаются на языках ООП, такая же, как и причина, по которой сопрограммы не часто встречаются на каком-либо основном языке, а именно.сопрограммы трудно реализовать при наличии обычного стека.

Мой ответ почти наверняка поздний, чтобы помочь оригинальному постеру.Я думал, что все равно отвечу, поскольку сопрограммы и другие формы параллелизма в настоящее время являются популярной темой.

Answer 3

Это всего лишь предположение:

Сопрограмма использует состояние подпрограммы , чтобы изменить свое возвращаемое значение, тогда как метод объекта может использовать состояние объекта , чтобы изменить свое возвращаемое значение.

Answer 4

Ну, на самом деле и Simula 67, и Smalltalk 80 - окончательный и окончательный язык OO - прекрасно поддерживали сопрограммы.Поэтому я сомневаюсь, что идея сопрограмм в принципе несовместима с ООП как таковой.Скорее всего, это совпадение, такой вопрос, как «почему классная штука X не поддерживается в языках mainsteam / операционных системах / и т. Д.»

Answer 5

Идея объекта состоит в том, чтобы изолировать состояние. Все, что вам нужно, должно присутствовать в этом объекте. Сопрограмма «сломает» эту идею, потому что теперь объект больше не является изолированным состоянием, а скорее зависит от другого объекта.

Answer 6

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

Я сам догадываюсь, что это в основном потому, что языки, которые включают сопрограммы (например, Concurrent Pascal, Concurrent C)(который на самом деле поддерживал C ++ того времени), и Ada Tasks вроде бы тоже похожи), никогда не становились особенно популярными.С технической точки зрения, эти проекты уже чрезвычайно хороши, но они никогда не стали особенно популярными.В некоторой степени, это, вероятно, вопрос времени так же, как и все остальное.К тому времени, когда стали доступны многопроцессорные компьютеры для того, чтобы параллельные вычисления стали настоящей целью для большинства программистов, эти языки уже были почти забыты.в основном, нужна хорошая «коммерческая подача», чтобы Concurrent C или Ada 95 (и т. д.) звучали как что-то новое и достаточно инновационное, чтобы люди хотя бы попробовали их.Конечно, реализации десятилетий назад часто были однопоточными - это потребовало бы обновления.Однако, для одного примера, я уверен, что реализации Ada 95 были обновлены, поэтому они вполне могут использовать несколько ядер.Похоже, это не сильно повлияло на его популярность (например, здесь, в SO, тег ada в настоящее время используется только 90 раз).