| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
|
типа хранится вместе со значением (как это и полагается для машин Лебедева,
которые, в отличии от машин фонНеймана — с самоопределяемостью данных). Вот
там возьмут и соорудят ассоциативный массив. Такой, где не только значения в
его ячейках но их индексы тоже могут быть совершенно любого типа. И в
результате получат самый общий случай структуры или записи, где индексы
строчного типа и будут именами полей. А новое поле можно добавить или удалить
в любой момент, когда вздумается.
А то, что все тамошние переменные — тоже ячейки вот такого же массива,
только более глобального, а их имена — это, соответственно, индексы...
Да, красиво, изящно, но, увы — не наш случай. У нас язык — всё еще ПЕРВОГО
поколения. (За то максимально простой!) С фиксированными, встроенными в сам
язык типами данных. (Более того — вообще с одним единственным.) Что, впрочем,
совсем не препятствует автоматически преобразовывать значения полей к этому
встроенному типу, а потом обратно. Особенно, если доступно описание полей,
как в том же *.dbf.
Вообще-то сперва я хотел просто разбить содержимое А2 на поля табулостопами.
А табулостопы эти сделать пронумерованные, или даже именами снабдить,
индивидуальными. С тем, чтобы ставить маркер на начало произвольного, какого
хочу поля, а не только следующего, как сейчас. И плюс к этому — чтение/запись
не "строки" (до ПС/ВК) а фиксированного количества байтов, при чем не взирая
на "непечатные" символы.
Но увы: просто поставить маркер на начало поля недостаточно. Надо еще чтобы
например то, что выдаст туда оператор Type в соседнее поле не перелезало. А у
нас это — запросто.
Впрочем, зная границы полей, извлечь, равно как и положить туда любую
числовую или текстовую информацию можно уже сейчас без всяких табулостопов:
форматный механизм оператора Write как раз под это и заточен.
Однако, с одной стороны сложновато: надо всё-всё-всё про эту структуру
знать. С другой — а как же поля ссылочного типа и навигация по ним?...
Поэтому пусть вся запись (структура) пусть будет где-то в другом месте, а в
аккамуляторы — только отдельные значения, извлеченные из её полей.
Подключим к этому делу идею двойной буферизации. "Двойная" она только для
ввода, поскольку у Ask еще и свой буфер есть. А вот этот, второй, нехай будет
привязан к файлу. То есть сперва мы читаем из него туда сразу всю запись
целиком. И уже из него таскаем значения отдельных полей. И в него же пишем.
Причем сразу с автоматическим преобразованием типа к типу поля. А буде захотели
следующую запись, то сперва (если писали и буфер — "грязный") сбросим обратно.
Типа "транзакция"? (Еще и, возможно, с блокировкой этого фрагмента. Некоторые
ОС позволяют...)
Но тренироваться, как известно, надо на кошках. За сим безо всяких
типизированных полей (и полей вообще) сделаем сперва буферизацию вывода. Для
чего завести буфер для оператора Type и писать не в канал вывода а в него. А
выпихивать из буфера в канал — только по '!'. Включать: Type %%% (благо
освободилось), а Ask %%% сделать не до конца оператора, как сейчас, а тоже
только до '!', и пусть буфер оно у Type перехватывает. И наоборот тоже.
(А буде надо это дело "спустить на тормозах" — не выдавать в канал вывода, то
'%!'.) За одно решится мелкая но неприятная проблемка с получением текстового
представления даты/времени. А то так исторически сложилось, что в отличии
например от имени найденного файла (ф-ей FTEll), оно, побочный эффект функции
FTMp, сразу в канал вывода. Неединообразно, но ломать всётаки не хочется.
* * *
Оказывается, каналов ввода/вывода у нас в Фокале не два, а три!
— канал ввода 'R' откуда читают оператор Ask, функция fchr() и сам Фокал
— канал вывода 'W', куда пишут операторы Type, Write, и функция fchr()
— и еще канал 'D' который археологи (в моём лице) раскапывают вот прямо
сейчас! Он указывает на текущий каталог и негласно применяется функцией
ftell() со строчным аргументом при поиске файлов, и оператором Operate при их
открытии. Но никаких других действий с ним пока не предусмотрено. Вернее, все
они — с помощью оператора ! командами операционной системы.
Итак, где-то там, в тридевятом царстве, в тридесятом государстве, вокруг
нас имеет место быть "внешняя информационная стреда", где обитают
информационные объекты, называемые сильно по-разному: "носители", "тома",
"контейнеры"... И некоторые из них вот прямо сейчас доступны нашей
вычислительной системе и обозначаются в ней буковками: "A:", "B:", "C:"...
(Обязательно с двоеточием — так исторически сложилось.)
Внутри у каждого такого тома — "внутренняя информационная среда" в виде
набора информационных объектов, для обобщенного обозначения которых нету
подходящего термина: "набор данных" — слишком громоздко и статично; "файл"
(от исковерканного германского "филе" — много) т.е. тоже множество, набор
данных — закрепилось за вполне конкретной разновидностью; "сегмент" — тоже
занято; "поток" — наоборот слишком "динамично" и ассоциируется не с хранением
а с передачей...
Пока временно остановимся на последнем слове. Тем паче оно уже кое-где
употребляется для примерно сходных целей. Придадим ему несколько расширенное
толкование по сравнению с интуитивно понятным, но пока не будем уточнять и
конкретизировать.
Эти самые потоки внутри тома или контейнера в общем случае никак не
упорядоченны. (Хотя возможны варианты. Например на магнитной ленте они строго
один за другим.) Но среди них есть один, выделенный, известный как "корневой
каталог". Это обязательно поток таких "записей" (или "структур"), в корорых
есть два следующих поля: первое из них содержит строку — "имя файла", а
второе указывает на поименованный таким образом поток. (Ну и возможно
дополнительные поля со всякими аттрибутами.) Поток, на который указывает поле
номер два, может быть такой же каталог, а может то, что обычно и называется
"файлом". (Хотя есть и другие варианты.)
Свеженайденный канал 'D' подключен к одному из таких каталогов — "текущему".
Функция ftell() с текстовым аргументом производит чтение всех записей этого
потока подряд, до тех пор, пока не найдёт такую, где значение первого поля не
подойдёт под шаблон, указанный текстовым аргументом. Оператор Operate делает
то же самое, плюс он этот файл еще и "открывает". Я бы сказал, что копирует
содержимое второго поля себе в спецпеременную, обозначаемую "псевдонимом".
(Только неправда это: выполняемые при этом действия куда сложне. Но снаружи
таки выглядит как будто бы оно вот именно так.)
Другими словами, для одного частного случая, специфическими средствами
операционной системы, реализованы некоторые из возможных действий с некоторыми
полями записей одного из типов потока (известного как "каталог").
Ага.
А я хочу — любые возможные действия с любыми полями элементов потока
произвольного типа. Ну или, как минимум (или для начала) чтобы Фокал открывал
с помощью оператора О и использовал не только потоки бестиповых байтов,
искуственно разделенных на строчки по символам ПС и ВК с кодами 10 и 13, но и
хотя бы некоторые другие.
А так как исходно сам Фокал заточен исключительно под строчки, то видимо
придётся сохранить концепцию главного поля, содержащего текстовую строку. И
по-умолчанию читать только его.
А эти самые "любые возможные действия" (в дополнение к уже имеющимся
операциям с числами и строчками) должны включать с одной стороны навигацию по вот этим
уже существующим ссылкам. А с другой — создание и уничтожение таких ссылок.
Типа записи другого значения в ссылочное поле. А так же создание новых
потоков и уничтожение существующих. (Не оставляя при этом ни "мусора" ни
висящих ссылок, указывающих на уже несуществующие объекты.)
И полюс к этому формирование структур данных — либо статическое создание
новых видов записи (и потока такого типа) с произвольными полями, либо
динамическое добавление и/или удаление полей.
Вроде всё?
Как — не вопрос. Ну например задействуем таки '%' в операторе Operate.
Пусть просто '%' означает сам А3 (типа: О () А; О % Б; это сделать из
псевдонима Б копию А), а с разными буковками пусть еще что-то значит. Например
%К — один из компортов (на самом дле что ни будь %К1/9600/2н чтобы сразу
указать номер устройства, скорость, количество стоповых битов и контроль по
четности), а %О — описание набора полей, "метафайл" к тому, указатель на
который в аккумуляторе: для каждого поля — одна запись с фиксированными
полями, типа "имя", "тип", "размер", "смещение", еще признаки какие ни будь...
("nm", "t", "l", "s", "f"...)
Ага-ага, заполучив каким-то образом в аккумулятор А3 указатель на поток,
мы теперь сможем открыть его под другим псевдонимом. Или даже под тем же
самым... А прочитав из него очередную запись, а из неё следующий указатель,
проделать опять то же самое... Чем не навигация?
* * *
Вот только было бы полезно еще и хоть как-то запомнить путь, чтобы можно
было вернуться обратно. Для этого введём в псевдоним в операторе Ask еще одну
буковку, например 'S'. ('N' там уже есть, чем 'S' хуже?!) Указывающую не
закрывать текущий файл, открытый под этим псевдонимом, при открытии под ним
другого, а как бы "отодвинуть вглубь". А как только этот будет закрыт -
восстановить на место.
Так можно запоминать не только текущие точки в потоке (смещения в файле),
чтобы потом вернуться к нему обратно, но и наделить этим свойством например
терминал с клавиатурой, чтобы нельзя было закрыть их окончательно...
* * *
Ну и зачем нам, спрашивается, после этого канал Д, если мы теперь сами
сможем перебрать все записи каталога и выбрав ту, что понравится, и просто...
А вот даже совсем и не "просто"! Во-первых это будет совсем не такое
элементарное действие, как сейчас открытие файла по его имени: А "имя" Х;
А во-вторых нешто мы не найдём для чего его приспособить в плане поиска по
базе данных с помощью штатных средств СУБД?...
* * *
Итого, у нас фактически остались два вопроса:
— как файлы (то бишь потоки) открывать не как текстовый/бинарный, а как
какой-то еще (в т.ч. с двойной буферизацией): как-то принудительно, или
автоматически по расширениею (или сигнатуре) распознавать?
— как описывать именованные типизированные поля с одной стороны так, чтобы
это было развитием идеи табулостопов, а с другой — чтобы они получались
привязаны либо к конкретному открытому под таким-то псевдонимом файлу, либо к
типу потока, о которых тоже надо подумать...
| Предыдущая глава |
↓ Содержание ↓
↑ Свернуть ↑
|
