История изменений

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

Изначальный план был таков: пишем атрибут «экспорт» в определении объекта, а дальше при сборке в качестве побочного эффекта образуется файл интерфейса со списком экспортов и, допустим, в него копируются докстринги.

Но тут всё не так просто. Если мы пишем слово «экспорт» в определении, это подразумевает разработку «снизу вверх».

Но бывает ещё разработка «сверху вниз», то файл интерфейса может придти от архитектора уже готовым. В этом случае не годится формировать его при сборке. Нужно его не трогать, а при сборке - _проверять_, все ли заявленные к экспорту имена должным образом определены. Более того, если мы разбиваем определение модуля на часть «что хотели», которая пишется руками, и часть «что получилось», которую делает среда, то экспорты получаются у нас в разных местах в зависимости от принятой методики разработки. Это сильно запутывает дело.

Так и не могу понять, как сделать это идеально.

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

Изначальный план был таков: пишем атрибут «экспорт» в определении объекта, а дальше при сборке в качестве побочного эффекта образуется файл интерфейса со списком экспортов и, допустим, в него копируются докстринги.

Но тут всё не так просто. Если мы пишем слово «экспорт» в определении, это подразумевает разработку «снизу вверх».

Но бывает ещё разработка «сверху вниз», то файл интерфейса может придти от архитектора уже готовым. В этом случае не годится формировать его при сборке. Нужно его не трогать, а при сборке - _проверять_, все ли заявленные к экспорту имена должным образом определены. Более того, если мы разбиваем определение модуля на часть «что хотели», которая пишется руками, и часть «что получилось», которую делает среда, то экспорты получаются у нас в разных местах. Это сильно запутывает дело.

Кроме того, если плоды труда компьютера писать в отдельный файл, то получится, что часть определения модуля (допустим, пр-во имён и состав файлов) будут в одном месте, а другая часть (экспорты) - в другом. Причём, состав этой части зависит от того, идёт ли у нас разработка сверху вниз или снизу вверх.

Так и не могу понять, как сделать это идеально.

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

Для этого пишем слово «экспорт» в определении объекта, а дальше при сборке в качестве побочного эффекта образуется файл интерфейфса со списком экспортов и, допустим, в него копируются докстринги.

Но тут всё не так просто. Если мы пишем слово экспорт в определении, это подразумевает разработку «снизу вверх».

Если мы разрабатываем «сверху вниз», то файл интерфейса может придти от архитектора уже готовым. В этом случае не годится формировать его при сборке. Нужно его не трогать, а при сборке - _проверять_, все ли заявленные к экспорту имена должным образом определены.

Кроме того, если плоды труда компьютера писать в отдельный файл, то получится, что часть определения модуля (допустим, пр-во имён и состав файлов) будут в одном месте, а другая часть (экспорты) - в другом. Причём, состав этой части зависит от того, идёт ли у нас разработка сверху вниз или снизу вверх.

Так и не могу понять, как сделать это идеально.