adimetrius писал(а):
Проверять существование файла открытием - это не способ, а хак.
а другого нам не завезли. вариант «каждый раз сканировать весь каталог» мне категорически не нравится: это потенциально медленная операция, и опять таки не гарантирует, что файл можно открыть для чтения. а мне надо такую гарантию.
adimetrius писал(а):
Не надо так. Вы его ненароком не закрываете после такого проверочного открытия?
нет, конечно. я в этой беседе тоже участвовал, даже цитировал диссертацию про ETHOS, из которой ясно видно, что закрывать файлы руками не надо. ;-)
adimetrius писал(а):
Писать везде руками процедуру FileExists (loc: Files.Locator; IN fname: Files.Name): BOOLEAN мб.б утомительно. Это как раз вспомогательная процедура, ее можно раз и навсегда реализовать в Files, и она будет опираться не на api платформы, а на средства в самом Files.
сам BBCB, кстати, в большинстве мест использует как раз открытие файла. именно по той же причине, по которой это делаю и я: в дальнейшем код этот открытый файл использует. тот же паттерн подразумевает и мой апи: если клиент вызывает `OldFile()` — то он и хочет потом файл читать. не вижу ни одной причины, по которой библиотекарь не может сразу клиенту открытый файл и выдать.
adimetrius писал(а):
Оказывается, что за этой, казалось бы, безобидной мелочью тянется целый айсберг.
совершенно верно. потому что «подсистема» в понятиях BBCB (как минимум в варианте Lament Configuration) — это отдельная сущность, один (лишь один!) из вариантов организации которой — подкаталоги на FS.
adimetrius писал(а):
И вот уже в оконную систему - казалось бы, до нее как до луны, но нет - вот уже и в оконную систему ББ мы вносим изменения и выкидываем, как было раньше, потому что оно не подходит.
ну, наглухо прибитое гвоздями расширение ".odc", а также имена подкаталогов в подсистемах — это лучше разве? то есть, мы делали-делали библиотекаря, который эти расширения и имена как раз возвращает, а потом раз! — и выкинули его в окошко, приколотив гвоздями некое знание о внутренней организации системы туда, где этого знания в принципе быть не должно. соответственно, абстракция «чёрный ящик» у нас превратилась в «серое решето».
adimetrius писал(а):
По пути, правда, добавляется ряд неоднозначностей (одному набору файловых координат локатор-имя уже соответствует не ноль или один, а ноль или один или два или Н файлов).
да. потому что данные подсистемы — не файлы, а документы. в один конкретный момент, в одной конкретной конфигурации у нас строго один вид на набор документов в подсистеме. соответственно, библиотекарь занимается отображением этого вида на постоянное хранилище — в данном случае на FS.
adimetrius писал(а):
И по пути, правда, увеличивается связность разных частей системы, что делает ее Просто Работающей и в перспективе - закоснелой.
но почему прибивать сакральное знание гвоздями в разных местах — это лучше, чем выделить это знание в один чёрный ящик, и потом обращаться к этому ящику? опять получается серое решето же.
adimetrius писал(а):
Всамделе, нагородили эти оминки - отдельно тексты, отдельно ридеры, отдельно сканеры. Собрать бы все вместе, да и... сделать свой винапи.
странный вывод. я не понимаю его генезиса.
adimetrius писал(а):
Я с начала этой темы сделал у себя полдюжины разных библиотекарей для разных целей (в т.ч. для гершеля несколько), и у меня возникал соблазн все собрать в монолит - сразу получать готовый файл или читатель/писатель. Эксперимент показал, что можно так сделать, но иногда нельзя; а значит, надо соблазн отвергнуть и связность не повышать. Я предпочел остаться с файловыми координатами.
а мой эксперимент в LC мне показал, что `GetSpec` в библиотекаре вообще не особо нужен: там, где он используется — почти всегда просто протекает абстракция. единственный случай, где мне легитимно понадобился локатор без файла/view — это в браузере подсистем. и то я подозреваю — это потому, что я недодумал API в этом направлении.
впрочем, вы (Борис, в смысле; простите, отчества не знаю) совершенно правы в том, что в LC библиотекарь в том виде, в каком он есть — не нужен. поэтому я его только что убил, и сделал вместо этого подсистему Subs, в которой живёт SubsManager.