Почему большинство объектно-ориентированных языков не поддерживает сопрограммы?
Я в настоящее время готовлюсь к экзамену. Один из вопроса, который я нашел на старом экзамене:
"Почему большинство объектно-ориентированных языков не поддерживает сопрограммы? (Подсказка: это - не потому что они поддерживают потоки)"
Проблема, что я не могу найти хороший ответ. Конечно, Вам не нужны сопрограммы, если бы у Вас есть объектная ориентация, но все еще было бы очень полезно иметь их в некоторых случаях.
3 ответа
Я думаю, что это из-за идеологических причины. В ООП основной сущностью, представляющей состояние , является объект. Ничто другое не должно иметь состояние . В мире сопрограмм они становятся еще одним носителем состояния, что немного противоречит ООП. В C # есть второстепенная версия оператора coroutine: yield, но это чисто особенность C #, а не сама среда CLR и .net, в то время как скомпилированные все переменные состояния становятся полями скрытого класса. Это потому, что ничто, кроме объекта, не может иметь состояния в .net.
Это просто предположение:
Корутина использует состояние подпрограммы для изменения своего возвращаемого значения, тогда как метод на объекте может использовать состояние объекта для изменения своего возвращаемого значения.
По мне, это похоже на паршивый вопрос для экзамена - он очень субъективен, и нет ни одного правильного или даже лучшего ответа. Короче говоря, я не думаю, что кто-то может сделать что-то большее, чем просто предположить.
Мое собственное предположение состоит в том, что это в основном потому, что языки, которые включали в себя корутины (например, Concurrent Pascal, Concurrent C (который фактически поддерживал C++ того времени), и Ada Tasks тоже в некотором роде похожи), так и не стали особенно популярными. С технической точки зрения, эти проекты уже чрезвычайно хороши, но они так и не стали особенно популярными. В какой-то степени это, вероятно, вопрос времени, как и все остальное. К тому времени, когда появились многопроцессорные компьютеры, сделавшие параллельные вычисления реальной целью для большинства программистов, эти языки уже были в основном забыты.
С технической точки зрения, я не уверен, что у кого-то есть что добавить нового - в основном требуется хорошее "торговое предложение", чтобы Concurrent C или Ada 95 (и т.д.) звучали как нечто новое и инновационное настолько, чтобы заставить людей хотя бы попробовать их. Конечно, реализации десятилетней давности часто были однопоточными под капотом - это потребует обновления. Для примера, я уверен, что реализации Ada 95 были обновлены, чтобы они могли использовать несколько ядер. Однако это, похоже, не сильно повлияло на ее популярность (например, здесь, на SO, тег ada в настоящее время использовался всего 90 раз).