Добрый день! Интересуют способы организации многофайловых проектов в различных языках программирования. Любая информация на тему — сравнительные характеристики, описания, мысли разработчиков на тему "почему сделано так а не иначе", "как лучше всего", ваше мнение.

Информации собранной воедино нет нигде. Да и в книгах ей уделяется второстепенное внимание. Я кроме С/С++ и немного C# мало чего знаю.

Способы организации многофайловых проектов
Синтаксисы подключения "модулей" в файл
(include, using и т.д.), особенности этого синтаксиса (составные имена модулей, алиасы, раскрытие пространства имен подключаемого модуля)
Разница между этими способами (c/c++ — прямое включение одного файла в другой, т.е. include; какие есть другие способы)
компиляция (раздельная пофайловая с последующей линковкой, какие-то другие способы — типа многопроходного парсинга всех файлов сразу, может что-то еще);
Особенности видимости имен между модулями (в С/С++ для подключения имени из другого файла необходим extern, в c# можно без этого)
Привязка к файловой системе (вроде в java имя модуля как-то привязано к имени файла)
Форматы хранения скомпилированных модулей (начиная от простейших obj/lib/a файлов которые предполагается использоваться в связке с заголовочными файлами, и далее, какие языки используют специализированные улучшенные форматы)
Ну и т.д.

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

Здравствуйте, 00011011, Вы писали:

0>может быть вопрос сумбурный, но надо с чего-то начать, чтобы понять какой должна быть архитектура идеальной модульной системы в языке программирования — на всех уровнях, начиная от внутреннего устройства для компилятора и заканчивая тем что видит программист в среде разработки.

То есть ты не знаешь ничерта и хочешь придумать идеальную "модульную систему"?
В добрый путь.

ЗЫЖ Прочитай хотя бы что такое модули

Здравствуйте, GarryIV, Вы писали:

GIV>То есть ты не знаешь ничерта и хочешь придумать идеальную "модульную систему"?

Не "не знаю ничерта" а скорее "отсутствует системное понимание". Я хочу его здесь получить.
Статью на вики я читал много раз. Но там тоже нет сравнительной таблицы разных реализаций.

Здравствуйте, 00011011, Вы писали:

0>может быть вопрос сумбурный, но надо с чего-то начать, чтобы понять какой должна быть архитектура идеальной модульной системы в языке программирования — на всех уровнях, начиная от внутреннего устройства для компилятора и заканчивая тем что видит программист в среде разработки.

Идеалов нет, универсального решения, которое бы всех устроило, тоже нет.

Для поиска своего идеала я бы посоветовал изучить, как сделана модульность в следующих языках: java, javascript, go, ocaml

Здравствуйте, scf, Вы писали:
scf>Для поиска своего идеала я бы посоветовал изучить, как сделана модульность в следующих языках: java, javascript, go, ocaml
А как же Pascal? Это ж фактически родоначальник модульного подхода.

Здравствуйте, 00011011, Вы писали:

0>Добрый день! Интересуют способы организации многофайловых проектов в различных языках программирования. Любая информация на тему — сравнительные характеристики, описания, мысли разработчиков на тему "почему сделано так а не иначе", "как лучше всего", ваше мнение.

Вот тут свежее обсуждение, на примерах Clojure, Kotlin, Rust и некоторых других:
https://tonsky.livejournal.com/323107.html

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

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, scf, Вы писали:
scf>>Для поиска своего идеала я бы посоветовал изучить, как сделана модульность в следующих языках: java, javascript, go, ocaml
S>А как же Pascal? Это ж фактически родоначальник модульного подхода.

В паскале модули-синглтоны. Ничего заслуживающего упоминания там нет.

Здравствуйте, scf, Вы писали:

scf>В паскале модули-синглтоны. Ничего заслуживающего упоминания там нет.
Не понял ни первую, ни вторую фразы.

Здравствуйте, Sinclair, Вы писали:

S>А как же Pascal? Это ж фактически родоначальник модульного подхода.
А что в Паскале за модули? Может в Turbo Pascal'е или Модуле?

Здравствуйте, pagid, Вы писали:

S>>А как же Pascal? Это ж фактически родоначальник модульного подхода.
P>А что в Паскале за модули? Может в Turbo Pascal'е или Модуле?
Mea culpa. Я почему-то решил, что unit там был с самого начала, а не в Borland Turbo Pascal.

Здравствуйте, 00011011, Вы писали:

0>Добрый день! Интересуют способы организации многофайловых проектов в различных языках программирования. Любая информация на тему — сравнительные характеристики, описания, мысли разработчиков на тему "почему сделано так а не иначе", "как лучше всего", ваше мнение.

Ниже привёл более-менее стандартную практику организации файлов на нескольких крупных C# проектах. Не могу сказать, что всё 100% идеально, но лучше многого, что приходилось видеть.

1. Солюшен обычно именуется по кастомеру и названию проекта. Варианты возможны, но это более-менее устоявшаяся практика. Например: Customer.Product. Как альтернатива, видел вариант с сокращениями Customer.Product до уникальных сочетаний вида Microsoft.VisualStudio -> MSVS. Тоже вполне себе рабочий сценарий, при условии что где-то есть табличка однозначных соответствий.
2. Солюшен может состоять из нескольких проектов. Если несколько проектов имеют одинаковую смысловую нагрузку (например, несколько разных сервисов, воркеров и т.д.), то они лежат в отдельной папке. При этом имя солюшена и имя папки включаются в имя проекта. Например, если есть сервис, который работает с аккаунтами и отдельный сервис, который работает с, допустим, библиотекой, то они будут лежать в папке Services с названиями проектов: Customer.Product.Services.Accounts и Customer.Product.Services.Library. Нужно это для того, чтобы, во-первых, обеспечить уникальность имён на тестовых серверах, на которых могут одновременно хоститься несколько проектов, а во-вторых, чтобы админы также могли легко идентифицировать заказчика/проект и по команде вида "проект с кастомером Customer закончился, можно погасить связанные с ним сервисы/базы и т.д." сделать это без вопросов вида "а кому принадлежит сервис ABC? нужно его гасить, или нет?".
3. Файлы внутри проекта, если их много, также группируются по папкам по логическому принципу. Ради 10-20 файлов огород, понятно дело, никто не городит, но если больше, то явно появляются папки. Внутри папок теоретически возможны подпапки, но это, обычно, уже довольно редкое явление. Самое главное здесь — не городить лишние папки на 1-2 файла без острой необходимости, так как при разветвлённой иерархии папок будет больше возни с using.
4. Сами файлы обычно содержат в себе ровно один класс(не считая вложенных классов)/интерфейс/перечисление и т.д. При этом имя неймспейса может как включать в себя имя папок (тогда точно не будет перекрытий имён и, самое удобное, по неймспейсу всегда можно будет точно сказать, где этот файл лежит на диске), так и нет (тогда достаточно подключить проект и станут разом доступны все классы). Видел оба решения, мне однозначно больше нравится первое. То есть файл Book.cs из папки Data сервиса Library содержит в себе класс Book, находящийся в пространстве имён Customer.Product.Services.Library.Data

Здравствуйте, 00011011, Вы писали:

0>Добрый день! Интересуют способы организации многофайловых проектов в различных языках программирования. Любая информация на тему — сравнительные характеристики, описания, мысли разработчиков на тему "почему сделано так а не иначе", "как лучше всего", ваше мнение.

0>Информации собранной воедино нет нигде. Да и в книгах ей уделяется второстепенное внимание. Я кроме С/С++ и немного C# мало чего знаю.

Андрей Александреску
Язык программирования D:

Поговорка гласит, что программу в 100 строк можно
заставить работать, даже если она нарушает все законы
правильного кодирования. Эта поговорка расширяема:
действительно, можно написать программу в 10 000 строк,
уделяя внимание лишь деталям кода и не соблюдая никаких
более масштабных правил надлежащей модульной
разработки. Возможно, где-то есть и проекты в несколько
миллионов строк, нарушающие немало правил
крупномасштабной разработки. Многие твердые принципы
разработки программного обеспечения также производят
впечатление расширяемых. Разделение ответственности и
сокрытие информации одинаково работают в случае
небольшого модуля и при соединении целых приложений.
Воплощение этих принципов, тем не менее, варьируется в
зависимости от уровня, на котором эти принципы
применяются. Эта часть посвящена сборке более крупных
сущностей – целых файлов, каталогов, библиотек и
программ. Определяя свой подход к крупномасштабной
модульности, D следует отдельным хорошо
зарекомендовавшим себя принципам, а также вводит пару
любопытных инноваций относительно поиска имен. 11.1.
Пакеты и модули Единицей компиляции, защиты и
инкапсуляции является физический файл. Единицей
логического объединения множества файлов является
каталог. Вот и все сложности. С точки зрения
модульности мы обращаемся к файлу с исходным кодом на D
как к модулю, а к каталогу, содержащему файлы с
исходным кодом на D, – как к пакету. Нет причин думать,
что исходному коду программы на самом деле будет
удобнее в какой- нибудь супер- пупер базе данных. D
использует «базу данных », которую долгое время
настраивали лучшие из нас и которая 402 Глава 11.
Расширение масштаба прекрасно интегрируется со
средствами обеспечения безопасности, системой
управления версиями, защитой на уровне ОС,
журналированием – со всем, что бы вы ни назвали, а
также устанавливает низкий барьер входа для
широкомасштабной разработки, поскольку основные
необходимые инструменты – это редактор и компилятор.
Модуль D – это текстовый файл с расширением .d или .di.

Аналогично устроено в java, только там подходит еще лучше — организация готового компонента(jar-файла)
использует аналогичную структуру, что позволяет полностью абстрагироваться от особенностей ОС — только файлы и каталоги.
Плюсую за такой подход.

Здравствуйте, varenikAA, Вы писали:

AA>Аналогично устроено в java, только там подходит еще лучше — организация готового компонента(jar-файла)
AA>использует аналогичную структуру, что позволяет полностью абстрагироваться от особенностей ОС — только файлы и каталоги.
AA>Плюсую за такой подход.

Мне почему-то привязка модульности к файловой системе не нравится.
Больше нравится как в C#: пространство имен может быть разнесено по нескольким файлам с произвольными именами, и символ, объявленный в одном файле, по умолчанию доступен в другом без всяких "import".

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

Здравствуйте, 00011011, Вы писали:
0>Мне почему-то привязка модульности к файловой системе не нравится.
В Java нет привязки модульности к файловой системе. Этот вопрос решается class loader-ом. Есть определённые традиции и класслоадеры, идущие из коробки; но ничто не мешает добавить свой лоадер, который будет резолвить имя класса по комфортным вам правилам.

scf>Идеалов нет, универсального решения, которое бы всех устроило, тоже нет.
scf>Для поиска своего идеала я бы посоветовал изучить, как сделана модульность в следующих языках: java, javascript, go, ocaml
+ Component Pascal в среде BlackBox Component Builder
Лучшая модульность из всего того, что я видел за 45 лет в ИТ.

Здравствуйте, 00011011, Вы писали:

0>Здравствуйте, varenikAA, Вы писали:

AA>>Аналогично устроено в java, только там подходит еще лучше — организация готового компонента(jar-файла)
AA>>использует аналогичную структуру, что позволяет полностью абстрагироваться от особенностей ОС — только файлы и каталоги.
AA>>Плюсую за такой подход.

0>Мне почему-то привязка модульности к файловой системе не нравится.
0>Больше нравится как в C#: пространство имен может быть разнесено по нескольким файлам с произвольными именами, и символ, объявленный в одном файле, по умолчанию доступен в другом без всяких "import".

0>В Ди в принципе нет пространств имен. Там каждый файл — модуль, правда имя модуля можно переопределить явно, да и не всегда имя файла можно использовать как имя модуля из-за набора символов.

Проблема C#, в том, что компилятор не знает где искать исходники, об этом знает файл проекта и msbuild, со сложной структурой.
Сейчас в коре, по умолчанию можно не указывать путь к исходникам, но тогда приходится отказаться от вложенных проектов(которые ранее логично располагались в подпапках — например — проект Persons — в подпапке проектs Persons.Client и
Persons.Server).

Если мне не изменяет память в javac достаточно запустить компиляцию из корня директории где располагается Main. Общие правила игры.
Знаешь файловую систему — знаешь принцип пакетирования.
Опять же упаковка в жар-файл. Любой ресурс можно в компонент засунуть, заменить, достать.
Сейчас правда, в коре натив завезли, но в режиме виртаульной машины лучше концепция простого архива.
Пытался на си писать, так там до сих пор нет простого способа внедрить ресурс в модуль.
Или отдельно хранить как файлы, что как мне кажется не гуд или учить много нужных вещей.