OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 20:38

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 118 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.
Автор Сообщение
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 21:33 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
arisu писал(а):
я вижу библиотекаря как средство для доступа к данным подсистем. если нам что-то надо из подсистемы: исходник, доку, ресурс, объектник, символьный файл — никто не должен руками лазить по FS,

Мне близка такая идея, потому что мы, в частности, занимались (и занимаемся) объектными хранилищами. Это действительно не ФС в классическом понимании, но и не библиотекарь в понимании данной темы.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 21:34 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
arisu писал(а):
Борис Рюмшин писал(а):
Arisu, у вас не тот библиотекарь, который изначально задумывался. Это уж точно. Тем более в BBLC он каких-то эпических габаритов.
я вижу библиотекаря как средство для доступа к данным подсистем. если нам что-то надо из подсистемы: исходник, доку, ресурс, объектник, символьный файл — никто не должен руками лазить по FS, добывая это. вообще не должен про FS думать, и про расположение тоже. вот у нас есть чёрный ящик «библиотекарь» — он всё знает про подсистемы, надо ходить к нему. половина функций там просто чтобы избежать копипасты, потому что я его встраивал «на живую», чтобы получить предварительную рабочую версию. интерфейс можно вдумчиво вычистить (и я это потом сделаю).

но идея именно такая: не просто получаем какие-то пути где-то в FS к каким-то частям подсистем, а в принципе весь доступ к подсистемам роутим через библиотекаря. по уму он вообще должен возврашать не файлы, а ридеры и райтеры — просто я ещё это не сделал. но идея именно такая.

p.s.: как вариант — библиотекаря вообще уничтожить, и действительно сделать это нашлёпкой над FS, со своим префиксом. и везде использовать пути типа "SUBSYS:Std/Mod/Abc.odc". но я идею библиотекаря сохранил, потому что мне нравится, что он не подразумевает хранение подсистем на файловой системе, и в принципе какие-то понятия файлов (см. выше про то, что надо возвращать Reader и Writer вместо File в будущем).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 21:42 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Иван Денисов писал(а):
Библиотекарь выдаёт карточку, а за книгой иди сам :) А может даже книга уже в руках. Вот про это писали в чате, и я соглашусь. Виды ведь по локатору и имени открываются.
вот от этого я как раз избавился, потому что тогда невозможно единообразно и централизовано сделать прозрачную подмену. вот я прошу у него, предположим, "Std/Code/WinMdi/Something.ocf". но "WinMdi" — это надстройка над "Win", и в большинстве случаев (но не всегда) на самом деле существует только "Std/Code/Win/Something.ocf", который и надо использовать. если библиотекаря просят принести уже открытый .ocf — он проверит наличие, и вернёт нужный. а если только карточку — то читатель пойдёт к полке — а там ничего. дальше читатель обязан будет знать внутреннее устройство полочек, и опять ножками проверять все нужные. вместо того, чтобы за него это сделал работник библиотеки, и принёс книгу на блюдечке, готовую к употреблению.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 21:44 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
Борис Рюмшин писал(а):
arisu писал(а):
я вижу библиотекаря как средство для доступа к данным подсистем. если нам что-то надо из подсистемы: исходник, доку, ресурс, объектник, символьный файл — никто не должен руками лазить по FS,

Мне близка такая идея, потому что мы, в частности, занимались (и занимаемся) объектными хранилищами. Это действительно не ФС в классическом понимании, но и не библиотекарь в понимании данной темы.
а тогда библиотекарь из данной темы получается вообще лишней сущностью, и его надо переименовать во что-то другое, и нагрузить как раз такими функциями. иначе зачем нам библиотекарь, если его задача получается размазаной по куче мест? то есть, я как раз пытаюсь сделать из библиотекаря более-менее герметичный интерфейс для доступа к данным подсистем, чёрный ящик, который каждый сможет заменить на другой, если понадобится, и сделать это ровно в одном месте. а всё остальное будет (ура, моя любимая фраза!) Просто Работать.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 22:16 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
arisu писал(а):
Иван Денисов писал(а):
Библиотекарь выдаёт карточку, а за книгой иди сам :) А может даже книга уже в руках. Вот про это писали в чате, и я соглашусь. Виды ведь по локатору и имени открываются.
вот от этого я как раз избавился, потому что тогда невозможно единообразно и централизовано сделать прозрачную подмену. вот я прошу у него, предположим, "Std/Code/WinMdi/Something.ocf". но "WinMdi" — это надстройка над "Win", и в большинстве случаев (но не всегда) на самом деле существует только "Std/Code/Win/Something.ocf", который и надо использовать. если библиотекаря просят принести уже открытый .ocf — он проверит наличие, и вернёт нужный. а если только карточку — то читатель пойдёт к полке — а там ничего. дальше читатель обязан будет знать внутреннее устройство полочек, и опять ножками проверять все нужные. вместо того, чтобы за него это сделал работник библиотеки, и принёс книгу на блюдечке, готовую к употреблению.

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

У вас своё какое-то видение библиотекаря задомнаперёдное. Должно быть так: вы у него просите WinMdi, а он вам вернёт локатор для "Std/Code/Win" и имя файла "Something.ocf" в этом локаторе. Всё это ваше добро с учётом платформ прекрасно реализуется и поверх задумки Евгения/Антона/Бориса, до которой я тоже потихноньку допёр (почти, и тоже у меня какое-то своё понимание похоже, которое я постараюсь до товарищей донести).


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 22:32 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
на самом деле я вообще прошу "Std/Code/Something.ocf", а библиотекарь разбирается. но это технические детали.

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

то есть, я просто переместил открытие файла по локатору из клиента в библиотекаря — потому что в подавляющем большинстве случаев это именно то, что клиент сразу и сделает всё равно. а для остальных нескольких случаев добавил API создания файла, и просто получения локатора.

итого: библиотекарь делает как раз то, что вы описали. но дополнительно выполняет ещё и самый вероятный заказ клиента. и помогает избежать неоднозначных ситуаций с «пропавшими/подменёнными файлами» как раз. то есть, это, по сути, уже не столько библиотекарь, сколько некий «менеджер данных подсистем». да, название надо бы поменять тогда.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 22:47 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
У вас получается провайдер данных уже, а не просто библиотекарь, я бы даже сказал дилер :)
Борис про файлы тоже говорил, но получается, что не обязательно файл будет создан. Ведь могла произойти ошибка во время компиляции, скажем, и до регистрации файла дело не дойдет. И ещё есть построители разных карт подсистем. Их задача только ссылки построить, а сами файлы можно и не открывать пока человек не кликнет на нужную ссылку.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 23:05 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Проверять существование файла открытием - это не способ, а хак. Не надо так. Вы его ненароком не закрываете после такого проверочного открытия? Я недавно писал об этом.

Писать везде руками процедуру FileExists (loc: Files.Locator; IN fname: Files.Name): BOOLEAN мб.б утомительно. Это как раз вспомогательная процедура, ее можно раз и навсегда реализовать в Files, и она будет опираться не на api платформы, а на средства в самом Files.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 23:24 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Начали (эту итерацию беседы про библиотекаря) с того, что "давайте вот тут для удобства добавим вторую процедуру - IntSpec уже почти есть, давайте еще ExtSpec".

Оказывается, что за этой, казалось бы, безобидной мелочью тянется целый айсберг. Вот уже это и не библиотекарь вовсе, и возвращает он не пути, а файлы, и не файлы, а ридеры, и никто не обязывает их позиционированными на нуле возвращать, можно же уже спозиционировать их "как надо" (кому-то), пусть клиенты читают, как им подсунули. И вот уже в оконную систему - казалось бы, до нее как до луны, но нет - вот уже и в оконную систему ББ мы вносим изменения и выкидываем, как было раньше, потому что оно не подходит.

По пути, правда, добавляется ряд неоднозначностей (одному набору файловых координат локатор-имя уже соответствует не ноль или один, а ноль или один или два или Н файлов).
И по пути, правда, увеличивается связность разных частей системы, что делает ее Просто Работающей и в перспективе - закоснелой.

Всамделе, нагородили эти оминки - отдельно тексты, отдельно ридеры, отдельно сканеры. Собрать бы все вместе, да и... сделать свой винапи.

Я с начала этой темы сделал у себя полдюжины разных библиотекарей для разных целей (в т.ч. для гершеля несколько), и у меня возникал соблазн все собрать в монолит - сразу получать готовый файл или читатель/писатель. Эксперимент показал, что можно так сделать, но иногда нельзя; а значит, надо соблазн отвергнуть и связность не повышать. Я предпочел остаться с файловыми координатами.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Понедельник, 13 Февраль, 2023 23:33 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Между тем, у нас в начале этой темы было обсуждение про то, что нужны еще Перечислители - подобие сканеров. И тогда было, кажется, общее понимание, что мухи и котлеты отдельно - что вычислять файловые координаты и открывать/создавать по ним файлы - это разные вещи и должны разными частями программы делаться.

Т.е. я полагаю, что разговор о некоем хранилище объектов в ББ - вполне уместен. Но не надо впихивать это в библиотекаря. Пусть была бы библиотека, и в ней - библиотекарь.

Например, есть библиотека самого ББ. Есть к ней библиотекарь - вычисляет координаты файлов.
А вот мы скачали расширение с сайта Гельмута Цинна, и он - собсно тоже библиотека.
А вот есть библиотечный сканер. Его можно подключить к любой библиотеке и посмотреть, что там есть в ее каталоге.
Т.е. нечто подобное методике Carrier-Rider-Mapper.

Хотя, возможно, нынешний библиотекарь это не Rider и не Mapper и не Carrier, конечно. Он именно получается вычислитель координат файлов.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 14 Февраль, 2023 00:04 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
Закончил рабочий процесс, и теперь приступаю к ванимательному чтению больших постов. А также к тому, чтобы пояснить позицию про направления, созданию грамотных примеров и собственно размышлений, "а не дурак ли я".

adimetrius писал(а):
Писать везде руками процедуру FileExists (loc: Files.Locator; IN fname: Files.Name): BOOLEAN мб.б утомительно. Это как раз вспомогательная процедура, ее можно раз и навсегда реализовать в Files, и она будет опираться не на api платформы, а на средства в самом Files.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 14 Февраль, 2023 00:05 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Вот такой интерфейс для узла ввода-вывода в CPM, кмк, позволил бы решить ряд решаемых задач - мне однозначно упростил бы жизнь и ускорил работу. Консольный компилятор ascii/odc-текстов с сообщениями об ошибках уже можно было бы публиковать.
Вложение:
CPM.png
CPM.png [ 134 КБ | Просмотров: 3057 ]

Последние две процедуры - Mark и Get - не обязательно выносить в узел ввода-вывода. Но! Если их вынести - то DevCPM вообще не будет импортировать ничего из Text и Dev!!
Вложение:
IMPORT.png
IMPORT.png [ 16.3 КБ | Просмотров: 3056 ]

Вот так бы выглядел IMPORT в DevCPM. Кажется, это было бы плюсом - опять-таки, понизило бы сцепленность системы. (Или связность - не упомню, которая из них ругательная :) )


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 14 Февраль, 2023 00:06 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
adimetrius писал(а):
Начали (эту итерацию беседы про библиотекаря) с того, что "давайте вот тут для удобства добавим вторую процедуру - IntSpec уже почти есть, давайте еще ExtSpec".

Оказывается, что за этой, казалось бы, безобидной мелочью тянется целый айсберг. .

Это ложное измышление, так как с arisu мы не общались на эти темы до этого треда от слова "совсем". У него какие-то свои задумки, а меня цель простая, доделать скорее этого библиотекаря и двигаться дальше внедрять наработкки arisu по элементам управления. Мы в чате с вами и Борисом как раз затеяли согласование интерфейсов. Чем и дальше занимаемся. Сейчас займусь подготовкой аргументации и демонстрационного примера.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 14 Февраль, 2023 00:09 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Иван Денисов писал(а):
Я нашел как раз такую процедуру в StdApi, так что она такая маленькая, что её можно копировать ситуативно, где понадобится. Я так понимаю, что её не стали экспортировать, как как она даёт слабые гарантии для надёжных систем... но это лишь догадка.


О, полезно знать. Экспортировать бы ее оттуда.
Кстати, возможно, рассмотреть StdApi тогда как сборник разных вспомогательных процедур? Если не хочется в "фундаментальные" модули засорять.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 14 Февраль, 2023 00:09 
Аватара пользователя

Зарегистрирован: Четверг, 08 Октябрь, 2009 15:00
Сообщения: 3774
adimetrius писал(а):
Вот такой интерфейс для узла ввода-вывода в CPM, кмк, позволил бы решить ряд решаемых задач - мне однозначно упростил бы жизнь и ускорил работу. Консольный компилятор ascii/odc-текстов с сообщениями об ошибках уже можно было бы публиковать.
Вложение:
CPM.png

Последние две процедуры - Mark и Get - не обязательно выносить в узел ввода-вывода. Но! Если их вынести - то DevCPM вообще не будет импортировать ничего из Text и Dev!!
Вложение:
IMPORT.png

Вот так бы выглядел IMPORT в DevCPM. Кажется, это было бы плюсом - опять-таки, понизило бы сцепленность системы. (Или связность - не упомню, которая из них ругательная :) )

Для 2.0 это слишком революционно, а так в целом интересная наработка. Можно будет отдельный тред завести под обсуждение каких-то новых вариантов организации компилятора. Оно ещё и с Гершелем как-то перекликается возможно ведь.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 14 Февраль, 2023 00:12 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Иван Денисов писал(а):
adimetrius писал(а):
Начали (эту итерацию беседы про библиотекаря) с того, что "давайте вот тут для удобства добавим вторую процедуру - IntSpec уже почти есть, давайте еще ExtSpec".

Оказывается, что за этой, казалось бы, безобидной мелочью тянется целый айсберг. .

Это ложное измышление, так как с arisu мы не общались на эти темы до этого треда от слова "совсем". У него какие-то свои задумки, а меня цель простая, доделать скорее этого библиотекаря и двигаться дальше внедрять наработкки arisu по элементам управления. Мы в чате с вами и Борисом как раз затеяли согласование интерфейсов. Чем и дальше занимаемся. Сейчас займусь подготовкой аргументации и демонстрационного примера.


В приведенной цитате текстуально отсутсвует что-либо про ваше общение/необщение с arisu. И я в этой идеологической связи вас не подозреваю.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 14 Февраль, 2023 00:15 
Аватара пользователя

Зарегистрирован: Суббота, 16 Февраль, 2008 02:47
Сообщения: 660
Иван Денисов писал(а):
Для 2.0 это слишком революционно, а так в целом интересная наработка. Можно будет отдельный тред завести под обсуждение каких-то новых вариантов организации компилятора. Оно ещё и с Гершелем как-то перекликается возможно ведь.


Гораздо революционней - ваше предложение про "направление".


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 14 Февраль, 2023 00:33 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
Предлагаю не заморачиваться и оставить библиотекарь в простом виде
Код:
DEFINITION Librarian;

   IMPORT Files;

   TYPE
      Librarian = POINTER TO ABSTRACT RECORD
         res: INTEGER;
         (lib: Librarian) GetSpec (IN mod, cat: ARRAY OF CHAR; OUT loc: Files.Locator; OUT name: Files.Name), NEW, ABSTRACT;
         (lib: Librarian) SplitName (IN name: ARRAY OF CHAR; VAR head, tail: ARRAY OF CHAR), NEW, ABSTRACT
      END;

   VAR lib-, stdLib-: Librarian;

   PROCEDURE NewStdLibrarian (loc: Files.Locator): Librarian;
   PROCEDURE SetLib (librarian: Librarian);

END Librarian.

То есть направление убрать. Библиотекарь штука пока для внутреннего использования, можно и поменять потом. Все остальные вариации на тему -- от лукавого. Потому что тут уже куча точек зрения и сделать надолго, как Иван хочет, явно не получится.

А вот со SplitName уже проблема, потому что он из ядра уехал. На него уже начали в таком виде опираться (конкретно, как на StdLibrarian.SplitName).

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 14 Февраль, 2023 00:38 
Администратор

Зарегистрирован: Вторник, 15 Ноябрь, 2005 01:14
Сообщения: 4695
Откуда: Россия, Орёл
adimetrius писал(а):
Т.е. я полагаю, что разговор о некоем хранилище объектов в ББ - вполне уместен. Но не надо впихивать это в библиотекаря. Пусть была бы библиотека, и в ней - библиотекарь.

Как показало вскры... практическое изучение вопроса, это дело вводится вместо Files.Locator, с заменой много чего ещё. Я думал, что можно как-то дополнить Files ещё одним интерфейсом в дополнение к Locator и Files, но это несколько кардинально, и не уверен, что имеет смысл для обычного ББ.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: #046 Библиотекарь модулей
СообщениеДобавлено: Вторник, 14 Февраль, 2023 00:43 

Зарегистрирован: Воскресенье, 25 Декабрь, 2022 23:14
Сообщения: 1163
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.


Последний раз редактировалось arisu Вторник, 14 Февраль, 2023 00:48, всего редактировалось 1 раз.

Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 118 ]  На страницу Пред.  1, 2, 3, 4, 5, 6  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 11


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB