Это как раз тот вопрос, который рассматривается во всех подходах. И каждый выбирает свой вариант. Для перебора используется централизация, мультиметоды, диспетчеризация. Добавление новых сущностей требует модификации кода или специальных приемов. Вы по сути предлагаете ОО обмен сообщения, глядя на сущности как объекты. Но можно на взаимодействие смотреть как на процесс в котором описывается взаимодействие напрямую с анализом данных обоих сущностей определенной комбинации. Выбор техники кодирования определяется разработчиком. Меня больше устраивает процедурно-параметрический вариант. Он более гибкий при добавлении новых функций и новых альтернатив, позволяя при этом не изменять ранее написанный код.
При любой парадигме вряд ли кто разбрасывает код по файлам, модулям или классам хаотично. Порядок всегда есть и связан с архитектурой проекта. Поэтому распределение по файлам может быть практически аналогично тому, как распределяются базовый и производные классы. Здесь нет противоречий между парадигмами. Все определяется культурой использования модулей.
На уровне PPC полиморфные функции могут контролироваться примерно также как при использовании абстрактных классов в C++. Обобщенная функция может быть абстрактной. Тогда все альтернативы должны быть обязательно реализованы. Если обобщенная функция имеет тело, то она, как и виртуальные методы, используется по умолчанию там, где нет ее замены.
В СССР это направление называлось эволюционной разработкой. Были работы: Фуксман А.Л. Технологические аспекты создания программных систем. Горбунов-Посадов, М. М. Расширяемые программы.
Процедурно-параметрический подход решает многие проблемы, представленные в Expression Problem.
Ну, не совсем так. Система, которая описана здесь (http://softcraft.ru/neuro/ni/p00/), была еще в начале 90-х и активно использовалась в дисциплинах. Под MS DOS. Если для истории интересны работы того времени, то они в списке литературы.
Вообще-то в Линуксе издревле основным понятием был процесс, а не объект. А по поводу парадигм и программирования существуют и другие мнения. Например здесь: http://softcraft.ru/
Для общего подтверждения давних увлечений фото из моих архивов с объявления результатов защиты ВКР. 14.06.2018. Сергей, желаю дальнейшей успешной работы! Продолжай писать. Надеюсь, что это будет мотивировать не только незрячих, но и тех, кто пока смотрит не дальше собственного носа.
Тогда обычно пробелы не ставились, а ставилась табуляция. Редакторы также не заменяли табуляцию пробелами. Поэтому был только один символ. Ну и привычка. Специально посмотрел свой код 1992 года. Да. Везде табуляция. Правда сейчас она у меня отобразилось в смещение, равное двум пробелам.
Может быть Вам стоит посмотреть на EO (Eolang), где все есть объект? А так хорошо бы продемонстрировать предложение примерами, чтобы слова о парадигме были отражены в коде...
Кто, как и кого...
Это как раз тот вопрос, который рассматривается во всех подходах. И каждый выбирает свой вариант. Для перебора используется централизация, мультиметоды, диспетчеризация. Добавление новых сущностей требует модификации кода или специальных приемов. Вы по сути предлагаете ОО обмен сообщения, глядя на сущности как объекты. Но можно на взаимодействие смотреть как на процесс в котором описывается взаимодействие напрямую с анализом данных обоих сущностей определенной комбинации. Выбор техники кодирования определяется разработчиком. Меня больше устраивает процедурно-параметрический вариант. Он более гибкий при добавлении новых функций и новых альтернатив, позволяя при этом не изменять ранее написанный код.
При любой парадигме вряд ли кто разбрасывает код по файлам, модулям или классам хаотично. Порядок всегда есть и связан с архитектурой проекта. Поэтому распределение по файлам может быть практически аналогично тому, как распределяются базовый и производные классы. Здесь нет противоречий между парадигмами. Все определяется культурой использования модулей.
Языков, в которых есть мультиметоды, сейчас хватает. Начиная с CLOS. В основном доступ к параметрам реализуется с использованием хеширования, что медленнее чем в ЗЗС. Сравнение и обзор есть в статье: Сравнение производительности для различных способов реализации мультиметодов. Системы анализа и обработки данных. – 2025. – № 4 (100). – С. 69–84.(https://journals.nstu.ru/vestnik/catalogue/contents/view_article?id=41742).
На уровне PPC полиморфные функции могут контролироваться примерно также как при использовании абстрактных классов в C++. Обобщенная функция может быть абстрактной. Тогда все альтернативы должны быть обязательно реализованы. Если обобщенная функция имеет тело, то она, как и виртуальные методы, используется по умолчанию там, где нет ее замены.
В СССР это направление называлось эволюционной разработкой. Были работы:
Фуксман А.Л. Технологические аспекты создания программных систем.
Горбунов-Посадов, М. М. Расширяемые программы.
Процедурно-параметрический подход решает многие проблемы, представленные в Expression Problem.
Ну, не совсем так. Система, которая описана здесь (http://softcraft.ru/neuro/ni/p00/), была еще в начале 90-х и активно использовалась в дисциплинах. Под MS DOS. Если для истории интересны работы того времени, то они в списке литературы.
Небольшое уточнение в названии кафедры. Кафедра НейроЭВМ.
Еще там есть и деструкторы. Это использовалось для поддержки процедурно-параметрического программирования в расширении языка Си: https://www.mais-journal.ru/jour/article/view/1766
В результате получился PPC - язык процедурно-параметрического программирования (http://softcraft.ru/ppp/ppc/).
Вообще-то в Линуксе издревле основным понятием был процесс, а не объект. А по поводу парадигм и программирования существуют и другие мнения. Например здесь: http://softcraft.ru/
Возможно. А может быть предыдущее поколение просто лучше знало русский язык?
Если интерес касается разных эволюций кода, то можно посмотреть здесь:
https://github.com/kreofil/evo-situations/tree/main/evolution
Старое описание ситуаций можно почитать отсюда:
http://softcraft.ru/ppp/simplesituations/
Из последнего: http://softcraft.ru/ppp/
Для коллекции. Код на Си. Ну, почти чистом Си (http://softcraft.ru/ppp/ppc/).
Что-то уже было в предыдущем поколении. И споры. И даже с кодом: http://softcraft.ru/paradigm/dhp/
Дежавю, однако...
http://алексейнедоря.рф/?p=518
https://gitflic.ru/project/alekseinedoria/trivil-0
http://digital-economy.ru/stati/разработка-языка-тривиль-первые-шаги-к-семейству-языков-часть-1
http://digital-economy.ru/stati/разработка-языка-тривиль-часть-2
http://digital-economy.ru/stati/разработка-языка-тривиль-часть-3-баланс
http://digital-economy.ru/stati/разработка-языка-тривиль-часть-4-реализация
Если это не перевод с английского, то где Тривиль?
Тогда обычно пробелы не ставились, а ставилась табуляция. Редакторы также не заменяли табуляцию пробелами. Поэтому был только один символ. Ну и привычка. Специально посмотрел свой код 1992 года. Да. Везде табуляция. Правда сейчас она у меня отобразилось в смещение, равное двум пробелам.
В 1990 году появился Turbo C++ 1.0. Если память не изменяет Turbo сменилось на Borland где-то в районе третьей версии.
Может быть Вам стоит посмотреть на EO (Eolang), где все есть объект?
А так хорошо бы продемонстрировать предложение примерами, чтобы слова о парадигме были отражены в коде...