Организация системы юнитов

[Utkin]

Итак, имеется некий гипотетический язык программирования. Хочется в него подключать библиотеки различной направленности (написанных на том же языке пока что). Возникает несколько вопросов:
1. Как правильно (разумно, просто, понятно и т.д.) организовать хранение/обращение/доступ к юниту.
2. Как разрешать конфликт функций (когда функция с одним и тем же именем существует в разных юнитах и происходит ее вызов).
3. Как избегать дублирование юнитов (когда разные юниты в дереве ссылаются на одну и ту же стандартную библиотеку например).

[waleri]

1) Не совсем понятно что значит "как хранить". Ну например в файле, а файл в папке... Или в архиве, но архив все равно содержит папки и файлы, так что сути дела это не меняет.
2) Пространством имен - например, имя юнита + имя функции. Или имя папки + имя файла.
3) А в чем дублирование, это как раз хорошо, когда разные модули пользуются одной библиотекой. Гораздо хуже, когда у каждого свои костыли.

[Stilet]

Как правильно (разумно, просто, понятно и т.д.) организовать хранение/обращение/доступ к юниту.

По полному пути. Имя файла модуля, имя функции\Переменки/объекта

Как разрешать конфликт функций

Полный путь.

Как избегать дублирование юнитов

А где тут дублирование?

[Vapaamies]

Настала моя очередь троллить. А что такое юнит? Понятие не раскрыто.

• Является ли юнит единицей компиляции? Единицей именования?
• В случае единицы компиляции является ли юнит эвфемизмом файла внутри языка или может быть разнесен по нескольким файлам?
• С точки зрения именования является ли юнит принудительным пространством имен? Умолчательным пространством имен? Изолированным пространством имен?
• Допустимы ли анонимные пространства? Могут ли существовать имена вне пространств?

Скажем, в Delphi модуль является единицей компиляции, эвфемизмом файла, принудительным, умолчательным, но неизолированным пространством имен, из-за чего фактическая работа идет с локальным анонимным пространством, где имена собраны с перекрытием согласно порядку в uses.

В Канторе же класс является единицей именования и единицей компиляции, но не эвфемизмом файла, поэтому может быть разнесен на произвольное число файлов-скриптов. Также класс является принудительным, умолчательным и изолированным пространством имен.

В Delphi, Java, D, C#, Питоне есть импорт модулей, порождающий то самое умолчательное анонимное простраство имен, в котором возможны конфликты. В Канторе же все публичные классы доступны друг другу, импорт планируется как необязательная фича.

[Utkin]

1) Не совсем понятно что значит "как хранить". Ну например в файле, а файл в папке... Или в архиве, но архив все равно содержит папки и файлы, так что сути дела это не меняет.

В памяти. Вот загрузилась основная программа. Нашли список юнитов, и? Как их хранить в памяти?

2) Пространством имен - например, имя юнита + имя функции. Или имя папки + имя файла.

Пространство имен не отменяет проблему. Я могу не знать что в каком-то еще юните есть такая же функция и чисто теоретически пространство имен может совпасть (из-за устоявшихся обозначений типа storage, main, browser и т.д.). Имя юнита + имя функции опять таки возможно в том случае, если проблема известна. Я могу не знать, что в списке есть какой-нибудь Add(), Erase(), Delete() и т.д. Что мне все юниты на предмет совпадения имени выверять?

3) А в чем дублирование, это как раз хорошо, когда разные модули пользуются одной библиотекой. Гораздо хуже, когда у каждого свои костыли.

В том, что нужно юнит грузить снова, ведь юнит нижнего уровня ничего не знает о юнитах и их зависимостях более высоких уровней. И вторая проблема, как можно распознать что загружаемый по другому пути юнит уже загружался ранее?

А что такое юнит? Понятие не раскрыто.

Совокупность функций, расположенных в одном файле. Программная единица.

Является ли юнит единицей компиляции? Единицей именования?

Это единица хранения функций в файле. Единица трансляции (сами там выбирайте компиляция/интерпретация).
Ну да, аналогия с Делфи мне ближе.

[Vapaamies]

Сообщение от Utkin

И вторая проблема, как можно распознать что загружаемый по другому пути юнит уже загружался ранее?

У вас каша в голове. Модули различаются по глобально-уникальным именам, так что такой проблемы никогда не возникает. Как в Delphi?

[Человек_Борща]

Итак, имеется некий гипотетический язык программирования. Хочется в него подключать библиотеки различной направленности (написанных на том же языке пока что). Возникает несколько вопросов:
1. Как правильно (разумно, просто, понятно и т.д.) организовать хранение/обращение/доступ к юниту.
2. Как разрешать конфликт функций (когда функция с одним и тем же именем существует в разных юнитах и происходит ее вызов).
3. Как избегать дублирование юнитов (когда разные юниты в дереве ссылаются на одну и ту же стандартную библиотеку например).

1. в пространствах имен.
2. Смотреть накол-во параметров, порядок параметров, типы данных. Если функции одинаковы, брать первую из множества копий. Предусмотреть явный вызов <namesapace>.<module>.<method>.
3. Проблема ложится на программиста. Другой путь? Это другой модуль. Главное чтобы модуль из пути А нельзя было 2 раза в uses прописать. Если 2 модуля используют 1 библиотеку то компилировать библиотеку, а потом просто ссылаться на неё.

В том, что нужно юнит грузить снова, ведь юнит нижнего уровня ничего не знает о юнитах и их зависимостях более высоких уровней. И вторая проблема, как можно распознать что загружаемый по другому пути юнит уже загружался ранее?

Выверять проект перед сборкой. Строить зависимости, откидывать неиспользуемые модули (нигде не используются в файлах проекта).

[Stilet]

Совокупность функций, расположенных в одном файле. Программная единица.

Однозначно полный путь. Ибо он уж точно уникален в пределах ФС. А если вдруг дублирование (в двух юнитах одинаковые функи) то давать юнитам Алиас, как in в Делфи в разделе uses.

[Utkin]

У вас каша в голове. Модули различаются по глобально-уникальным именам, так что такой проблемы никогда не возникает. Как в Delphi?

Так если имена различаются, а содержимое идентично, Вам такой вариант в голову не приходит?

Однозначно полный путь. Ибо он уж точно уникален в пределах ФС. А если вдруг дублирование (в двух юнитах одинаковые функи) то давать юнитам Алиас, как in в Делфи в разделе uses.

Альяс хороший вариант для момента когда проблема известна, да стоит задуматься над этим. Полный путь в пределах ФС может вести в конечным итогам к одним и тем же юнитам, находящимся в разных папках.

[Vapaamies]

Сообщение от Utkin

Так если имена различаются, а содержимое идентично

Так это и есть каша в голове. По-умному называется "отсутствие проектирования". К языку не имеет никакого отношения, только если вы не хотите решить задачу доказательства эквивалентности кода в том или ином виде -- то есть научиться формально доказывать, что физически разные участки кода на вашем языке делают одно и то же. Это сильно выходит за рамки модульности, я бы сказал.