| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
|
Вот где-то так. Но это только для .dbf
Файл, содеражщий потоки, на вроде .wav надо сперва открывать как каталог.
И выбирать там один из потоков по имени. С потоком пакетов по-видимому придётся
делать две разные вещи — либо объединять содержимое всех следующих друг за
дружкой однотипных пакетов в один непрерывный поток. Автоматически. Открыв этот
виртуальный поток под другим псевдонимом. Либо таки рассматривать каждый пакет
индивидуально — как "дейтаграмму". (Иковерканное "датаграмма" — аналог
телеграммы.) Так же как отдельную очередную запись из .dbf
Самое непонятное — что делать с .html? С .xml вроде как следует поступать
так же как с поледовательностью записей. Но обратим внимание — каждая такая
запись содержит два выделенных поля: имя тега и содержимое — поток. То есть как
полагается каталогу. Отличие только в том, что там все имена уникальные, а тут
нет. А еще — там в заголовке могут быть какие угодно дополнительные поля. В том
числе и заранее неизвестные. У .html — то же самое. Но там это объективно
сущетсвующие параметры просмотрщика, которым временно (до закрывающей скобки)
придаются новые значения. Получается, что у .html-евской записи ну просто куча
нигде заранее не описанных каких угодно полей (правда все одного типа:
фрагмент строки), а не как у .dbf — фиксированный набор, и целый стэк значений
для каждого. То есть если даже такого поля никогда небыло, то обращение к нему
это не ошибка, но значение у него — строка нулевой длины.
Как это сделать — впринципе понятно. Но черт возьми, как же это громоздко
получается!
* * *
Следующая наша проблема это описание полей. Именованных. Оно должно быть
организовано по аналогии с устанавливающим табулостопы спецкомментарием из
одних двоеточий. Что-то типа: :имя_поля1 :имя_поля2 :имя_поля3... !
Ага. Но с одной стороны надо еще указывать тип поля. (Например как в .dbf,
где тип — это одна буковка.) При чем запросто может получиться так, что имя
поля плюс тип в нём не помещаются. И тогда размер поля тоже придётся указывать
явным образом. А вот с другой: если табулостопы привязаны к терминалу, и
существуют в единственном экземпляре (т.е. глобальные), то тут всё не так: у
каждого файла — свой набор полей. Пусть даже и частично одинаковых. За сим
требуется привязка к файлу, что-то типа: @имя_файла :имя_поля1: имя_поля2... !
Вот только имя файла здесь не очень-то подходит. (Ну разве что в качестве
значения по-умолчанию.) Фактически это метафайл. (Вернее метапоток — поток
метаинформации для некоторого потока.) Он может быть встроенным в заголовок
файла, как для .dbf или и вовсе виртуальным. И плюс к этому нам пожалуй
пригодился бы виртуальный каталог — список вот таких метафайлов, автоматически
пополняемый по мере открытия файлов или ввода вот таких вот описаний,
изобретением которых мы вот сейчас и занимаемся...
Как мы это собираемся использовать? Ну например так: Open псевдоним = имя
Помнится, когда-то давно, это было полным синонимом для: Open "имя" псевдоним
Впрочем это была "учебная" реализация базового Фокала "первый блин", который и
в самом деле получился тогда немножко комом... Сейчас же будет назначение
потоку новой структуры. С текущего места...
Итак, если поток — это поток записей, то и мета-поток к нему это тоже поток
записей, каждая из которых описывает одно поле. А мета-мета-поток — один для
них для всех... Или не один а всего лишь одинаковый? Потому что хочется, чтобы
к каждой такой записи, описывающей одно поле, прилагалось еще и его значение.
Что значит "прилагалось"? Надо уточнить. Пока что я это понимаю так, что
вот у меня есть открытый файл (поток); его указатель чтения/записи указывает на
некоторый его элемент; этот самый элемент (запись разумеется) уже считан и
находится в связанным с этим файлом буфере. А каждая запись метапотока имеет
указатель на то поле этого буфера, которое описывает. На предмет получения
оттуда содержащегося в этом поле значения.
Ага-ага: теперь надо уточнять, что значит здесь слово "получение"?
Ну как "что" — вот например у нас есть файл (поток) открытый под
псевдонимом П; под псевдонимом Q открываем его метафайл: Ope () П; Ope %M Q
и теперь написав что-то типа: Ope QS; Write %M; Ope %; получаем нечто типа:
@имя_метафайла :имя_поля1 = значение1 :имя_поля2 = значение2 .... ! (или ;
и продолжение в следующих строках — если не поместилось в одну). Где после
знака = (равно) — содержимое соответствующего поля из текущей записи файла,
открытого под псевдонимом П. Ага.
Сделать то вот такое для одного этого частного случая вполне можно. А для
общего? Для общего получается, что эти самые "значения" — значения одного и
того-же поля. Уж не знаю (пока) как оно называется, но не слишком ли круто?
Получается, что у каждой записи метафайла это поле будет разное — в точности
того типа, как описывается самой этой записью. Ну и что, что метафайл -
виртуальный. Договорились же, что в потоке записей, все записи одинаковые!
Ну ладно, пусть таки это поле типа указатель на поток из одного элемента.
При чем со свойством автоматического разыменования, как в Си-плюс-плюсе то ли
"указатель" то ли "ссылка" (вечно я названия этих адресных типов путаю).
Ха! А как он вообще выглядит, этот самый "общий случай"? Как... Ну например
мы откроем вот этот вот мета-файл, найдя его в оном виртуальном каталоге
мета-файлов. Пока правда не знаю как это сделать. В смысле как переключить на
него канал "Д", но возможно придумаю. И тогда, спрашивается, на какие именно
поля какого из нескольких сответствующих данному метафайлу потоков будут
направлены все эти ссылки? Учитывая, что может их и вправду несколько, а может
и ни одного — все уже закрыты или еще даже не открывались (и/или даже и не
созданы), но было заранее введено описание...
О котором я опять благополучно забыл!
Ну в общем — да: получается что метафайл сам по себе, но будучи открыт, он
всегда связан с каким-то конкретным файлом, или же пока ни с каким — тоже
виртуальным — только чтобы было где хранить начальные значения, буде они
указаны в описании. Форму и вид которого я так старательно отлыниваю придумать.
Придумать осталось каким образом обозначаем параметры поля. Имя это имя,
оно после двоеточия обязательно первое. Значение всегда последнее — после знака
= (равно). А вот остальные параметры...
— номер по порядку — например #число
— смещение от начала записи — например +число
— размер поля — например *число
— тип поля — например /буковка (пусть такая же как в .dbf)
— комментарий — после ; или ! и до конца строки
Пусть там где нужно число, может быть числовое выражение в любых скобках, а
там где буковка... Вот если бы нам надо было ограничиться только файлами типа
.dbf то позаимствовали бы оттедова оные буковки и всё:
"C" — символьное
"N" — числовое
"L" — логическое
"D" — дата (типа: ГГГГММДД)
"F" — число с плавающей запятой
"M" — "мемо" — хранящийся где-то отдельно текстовый комментарий (вернее десять
цифр — его адрес в файле типа .dbt)
Вот только для общего случая этого категорически недостаточно. Потому что
например число здесь вовсе не двоичное, а последовательность цифр. И вообще
похоже, что этот самый .dbf (вернее его основной поток) типа насквозь текстовый.
И вот с помощью этого не получится как-то описать даже заголовок самого этого .
dbf-овского файла.
И, кстати, в форматном преобразовании (это которое "еще более форматное",
чем само форматное выражение оператора Write %): ={X%формат} и #{Y%формат}
у нас вообще-то примерно такая же проблема. А еще хочется, чтобы буковки,
обозначающие типы здесь и форматы там были одни и те же или хотя бы как-то
между собою согласованы. А там у нас — буковки, позаимствованные у Сишных
функций printf() и scanf() (с их же помощью и реализовано):
d i o u x — целое число (десятичное, 8 и 16-ричное, беззнаковое...)
b — тоже целое, но бинарное
e f g — плавающее
c s — символы
При ближайшем рассмотрении ни то ни то нам не годится. Подходит только в
первом приближении: у функций printf() и scanf() формат должен описывать в
первую очередь их аргументы, что для нас неактуально — нам надо только то, во
что их преобразовать. Так что буковки D O X B обозначающие десятичное,
восьмеричное, шестнадцатиричное и двоичное (какового, кстати у printf() и
scanf() нет) — да, пригодятся. А вот U указывающее что аргумент беззнаковый...
А вот I... Ха, это только при выводе I дублирует D, а при вводе он распознаёт
числа вида 0xNNN 0NNN 0bNNN
продолжение следует
| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
|
