В Телеграм-чате "BlackBox 2.0" Иван преложил вот такое изменение в интерфейс библиотекаря:
Цитата:
PROCEDURE GetExtSpec* (mod, cat: ARRAY OF CHAR; OUT loc: Files.Locator; OUT name: Files.Name);
на запись
PROCEDURE GetIntSpec* (mod, cat: ARRAY OF CHAR; OUT loc: Files.Locator; OUT name: Files.Name);
на чтение
У меня вот такие соображения.
1) Я предлагал библиотекарь для унификации вычисления путей во всем каркасе, а не для
Цитата:
чтобы брать кодовые файлы из одного места пока среда работает и "развертывается" динамической загрузкой, а артефакты компиляции была возможность складывать в другое место.
Еще раз: моя задача была собрать в едином месте все вычисления путей, чтобы это не было "размазано" по каркасу и по прикладным подсистемам.
2) Я делал перекрестный компилятор, и в нем потребовался специализированный библиотекарь, именно в силу перекрестности. Опишу в следующем сообщении.
Почему потребовалось указание "направления" в том интерфейсе, который Иван предлагает - IntSpec/ExtSpec - мне не понятно, и Иван не пояснил, какую, например, задачу он решает.
3) Поясню. Допустим, нужно перекомпилировать модуль ПрилМ, импортирующий ПрилН, причем в ПрилМ добавлена экспортированная переменная. Компилятор для этого издаст запросы:
А) Прочесть Прил/Сим/Н.осф - прочесть символы импортированного модуля
Б) Прочесть Прил/Сим/М.осф - прочесть прежнюю версию символов компилируемого модуля М
В) Создать новый файл Ф в Прил/Сим - записать обновленную символьную информацию для М
Г) Зрегистрировать Ф под именем М.осф - зарегистрировать обновленный символьный файл
В этом сценарии путь везде один и тот же - Прил/Сим. Так работает StdDialog.GetSubLoc в прежних версиях, так работает StdLibrarian, который мы согласовали ранее, и реализацию которого я предложил.
Заметьте, что компилятор нигде не указывает направление IntSpec или ExtSpec. Для этого в прежних ББ не было предусмотрено ничего.
Усложнение происходило в файловой системе ББ. Они и ранее была двухэтажной, а в версии 2.0 мы экспериментируем с трехэтажной. Но это усложнение было аккуратно реализовано внутри ФС, и никуда вне модуля Files не расползалось.
Из-за многоэтажности запросы А и Б приведут к рабочему этажу, если соответствующий файл есть в рабочем этаже; или к стандартному этажу, если в рабочем этаже нет соответствующего файла.
Запрос В гарантированно приведет к рабочему этажу.
Т.е. локатор - везде один и тот же, Прил/Сим. Но для Files.dir.Old(Ф1) модуль ФС решает, что Прил/Сим => РАБОЧИЙ/Прил/Сим/Ф1, если там есть Ф1, или СТАНДАРТНЫЙ/Прил/Сим/Ф1, если в рабочем нет Ф1. А для Files.dir.New модуль ФС решает безусловно, что Прил/Сим => РАБОЧИЙ/Прил/Сим.
Все эти запросы разрешаются НЕ библиотекарем, а файловой системой. Библиотекарь и компилятор остаются простыми - с их т.зр. существует единственный путь Прил/Сим, без дифференциации на IntSpec/ExtSpec.
Все это прекрасно работало ранее и работает сейчас в 2.0.
Откуда возникает необходимость различать направления? Какую конкретно задачу вы решаете, что она потребовала от вас дифференциации путей при чтении и записи?
Замечу, что при разделении на IntSpec/ExtSpec возникает неясность "на следующем шаге". Вот вы запросили ExtSpec, записали туда файл, закрыли. Вскоре вам потребовалось его прочесть (вы снова компилируете). Теперь IntSpec приведет вас куда? к старой версии? Или к новой? Если эти процедуры в библиотекаре, то решать это должен он. А как он это будет решать?
Кроме того, библиотекарь мыслился как сервис для всего каркаса и всех приложений. Это что, выходит, все должны всегда дифференцировать - я хочу читать сейчас, а сейчас писать? Чем обосновано такое усложнение для третьих лиц?
Это было бы колоссальное усложнение. И пока даже не ясно, чем оно могло бы быть обосновано.