История изменений
Исправление monk, (текущая версия) :
Почему бы вместо этого не использовать нормальный современный язык с прямой, не костыльной реализацией ООП
Потому что для разных задач нужны разные реализации ООП. И если в хорошем языке можно просто использовать разные библиотеки и иметь в одной задаче CLOS (с поддержкой мультиметодов, аспектов, пре- и пост- методов и т.д.), а в другой (в той же программе) — простое ООП с минимумом overhead'а.
А в ваших «нормальных современных» приходится на каждую реализацию ООП по языку писать: AspectJ, C++ Open Method, ...
Исходная версия monk, :
Почему бы вместо этого не использовать нормальный современный язык с прямой, не костыльной реализацией ООП
Потому что для разных задач нужны разные реализации ООП. И если в хорошем языке можно просто использовать разные библиотеки и иметь в одной задаче CLOS (с поддержкой мультиметодов, аспектов, пре- и пост- методов и т.д.), а в другой — простое ООП с минимумом overhead'а.
А в ваших «нормальных современных» приходится на каждую реализацию ООП по языку писать: AspectJ, C++ Open Method, ...