А.С.Дружинин

Философия ОД

Настоящие заметки в некотором смысле подводят итог более чем годичных размышлений на тему "Так какой же qWORD нам нужен?". Как всегда, автор - народ, я лишь попытался сформулировать некоторые общие положения по итогам многчисленных обсуждений. Естественно, таким образом, как я сам это понимаю.

Для начала - некие тезисы.

1. qWORD5 задумывался как саморазвивающаяся система, писанная на самом себе
2. Для был этого нужен:
   1. Набор самодостаточных структур данных
   2. Самодостаточный набор методов, позволяющий рабоать как с "пассивными" объектами (записями и атрибутами записей), так и интерфейсными объектами (данные + скрипты)
   3. Программное ядро(интерпретатор данных), реализующее работу с базовыми структурами данных с помощью базовых методов
3. Одни и те же структуры данных и методы должны использоваться для разных компонент системы - серверных компонент, клиентских компонент, дизайнера клиентских компонент
4. Основное в qWORD5 - не конкретные решения, а сам принцип п.3 для реализации п.2

Под базовыми структурами данных понимаются некие абстрактные информационные объекты для хранения в БД и реализованные средствами языковой среды (в свое время - MSM)

Какие же базовые структуры были выбраны, и оказались ли они самодостаточны?

В качестве базовых структур данных были выбраны всего две сущности:

1. "Хранилище" данных - Запись + атрибуты (Экземпляр фрейма-понятия). Вообще говоря, это абсолютно стандартный объект данных реляционной модели, да и практически любой БД
2. "Словарь ключей" - дуальная структура, предназначенная для хранения ссылок на записи, содержащие конкретные значения конкретных атрибутов записей. Сама по себе не является фундаментальной и необходимой, но приносит такую массу удобств, что без нее ничего содержательного не сделаешь.

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

Принципиально базовые методы делятся на два больших класса:

1. Методы, обеспечивающие работы с объектами данными, как таковыми вне всякой привязки к интерфейсным элементам (в дальнейшем мы будем называть их активными объектами). Естественно, это джентльменский набор методов, присутствующих в любой БД:
   1. Работа с атрибутами записей (чтение, модификация, удаление, создание)
   2. Работа с записями (--""--) + навигация по записям со всяким фильтрами (условиями) на экземпляры записей, значений атрибутов
   3. + специфический набор методов для работы с объектами данных активных объектов, реализующий в некотором смысле наследование свойств. Ключевым здесь является переопределение умолчаний.
2. Методы, обеспечивающие интерпретацию активных объектов, созданных qWORD'ом для работы с информационными объектами. Ключевым здесь являются два момента:
   1. Общий метод "Выполнить метод" (гиперфункции $$D,$$F) - обеспечивают "вычисление" точки входа в М-программе, реализующей тот или иной метод (называемый событием)
   2. Общий метод "Действия по изменениям" - обеспечивает общий алгоритм интерпретации активных объектов, сконструированных qWORD'ом.

Естественно, действует универсальный закон - чем более общие сущности используются, тем меньше конкретных результатов можно получить.В соответствии с этим принципом была произведена специализация структур данных и методов работы с ними - введен иерархический ключ, т.е. ему была придана некоторая структура, причем вид этой структуры мог устанавливать разработчик. Сути дела это не меняет - появилась возможность дополнительной структуризации записей и их атрибутов, что тут же и было использовано:

• В структурах данных, предназначенных для конструирования и хранения активных объектов (фреймы, понятия, экраны...)
• В структурах "пользовательских" данных - Обобщенный Документ.

Де-факто, стало возможным легко реализовывать логически иерархические деревянные структуры данных, используя только общие для всех баз данных сущности запись-атрибут записи, которые, в свою очередь, на самом нижнем уровне реализовывались через физические деревья! (круг, в некотором смысле, замкнулся).

Подчеркну очень важное обстоятельство, что специализация коснулась только одной сущности - структуры ключа. Ровно поэтому в базовых методах изменять ничего не пришлось. Однако такой подход предполагает и известную замкнутость - текущий релиз qWORD'а  способен на всю мощь работать только с теми структурами и объектами, которые он создал сам!

Даже это - грандиозное достижение, и пример тому - развитие парадигмы обобщенного документа. Оказалось, что реализации логически деревянной структуры данных и набора связанных с этой структурой специализированных методов достаточно для саморазвития ОД только средствами, заложенными в нем самом! Подчеркну, что это касается только информационных объектов. Для активных объектов ничего не меняется - используются общие методы и структуры qWORD'а. Однако и здесь удалось исхитриться, и перейти от дизайнирования активных объектов и переопределения их методов к их гиперпараметризации. В чем смысл - а просто в рамках парадигмы ОД были созданы промежуточные структуры метаданных (например, описатель свойств папки), с которыми можно работать только узким набором  методов, специфичным для ОД, а окончательную раскладку по атрибутам и записям, требуемую интерпретатором активных объектов, можно проводить автоматически. После чего все благополучно работает под управлением qWORD'а как интерпретатора.

Заметим, что в некотором смысле ОД удовлетворяет всем базовым принципам, положенным в основу qWORD. Осталось одно маленькое но: ОД не является интерпретатором объектов, которые созданы в его парадигме.

1. Возникает вопрос, а что нужно добавить в ОД, дабы он приобрел такое свойство "самоинтерпретируемости"?
2. Связанный с ним вопрос, а сколько нужно добавить в ОД, чтобы он стал таким? Если весь оставшийся qWORD, то делать этого не надо.
3. Третий вопрос - а нужно ли, чтобы объекты, сконструированные qWORD'ом (или отдельные классы объектов, например) интерпретировались обязательно им самим?

Ответом на эти вопросы мы и занимались последний год. Отталкиваясь от подходов, намеченных и частично реализованных в ОД, возникает естественный вопрос - а что целесообразно внести в базовый qWORD? Предлагаемые варианты ответов - ниже

1. qWORD - База данных ссылок на объекты, как свои собственные, так и "чужие". База данных собственных объектов. База данных и реестр собственных методов.
2. qWORD - Интерпретатор практически произвольных объектов, лишь бы с ними можно было работать из М-среды (или из объекта, сконструированного qWORD'ом и интерпретируемого другим агентом)
3. qWORD - Конструктор объектов(данных и части методов) не только для себя, но и для других сред исполнения (в той мере, в какой это возможно и целесообразно. Довольно очевидно, что это будут, как правило, интерфейсные объекты, однако не исключается возможность реализации объектов данных на клиенте)

Вот, собственно, и вся триада, которую надо бы развивать на основе имеющегося опыта и представлений:

• Дополнение структур данных;
• Расширение набора методов;
• Стандартизация протокола обмена сообщений

Какие новые базовые структуры данных нам желательны? Ответ - см. здесь. Очень странно, что имея дерево в качестве фундаментальнейшей физической структуры данных, на которой реализовано сейчас все, не иметь точно такой же логической структуры и специфического набора методов работы с ним. Во-всяком случае, уж для серверных-то компонент это точно необходимо. А для клиентских это необходимо ровно так же! Ведь вся объектная парадигма - это одно сплошное дерево, реализуемое с той или иной степенью успешности в той или иной языковой среде. Перечисляю (только мне известное: HTML; JavaScript; Java; VisualBasic,...)

Если мы реализуем как базисную новую структуру - дерево, у нас (в М) останется только один стратегический резерв, выгодно отличающий нас от большинства остальных систем - возможность работы с именами, как с данными. Почему бы не использовать эту возможность там, где это можно? Работа с именами, как с данными и позволит нам реализовать  п.1 предлагаемых ответов. Что такое объектная ссылка, как не имя объекта? Почему мы не можем хранить в qWORD'овской БД только ссылку на объект, а все его атрибуты и прочее - пусть он сам хранит, применяет и т.п.? Не понимаю, что этому мешает? Идя таким путем, мы бы могли воспользоваться разделением труда - зачем нам реализовывать все самим, если это кто-то уже сделал? Ведь не переписываем же мы с начала до конца базовую ОС? Зачем нам все втаскивать в нашу БД, если у объекта есть свои собственные хранилища? Внесем в нашу БД только часть информации об объекте, достаточной для его однозначной идентификации и поисков по значениям, и хорош.

Вторая ипостась тесно связана с первой. Если мы допускаем хранение ссылок на объкты (для нас - это просто данные, к которым применима большая часть общих методов qWORD'а), то естественным было бы допустить и активность этих объектов, т.е. если у него есть методы, то иметь возможность их выполнять, как, вообще-то во всем мире и делается. Тогда ActiveX'ы быстро станут неотъемлемой частью qWORD'а, и сам он сможет предоставлять свои объекты данных  как ActiveQ (ясно, что все запихать в один модулечек нам не удасться, потребуется среда для их интрепретации и исполнения, ну и что? Для того, кто вызывает, это будет выглядеть как классический ActiveX).

Третья ипостась - приятное, но очень желательное дополнение. Можно, конечно, объявить весь qWORD набором объектов, и вызовы к ним писать из другой среды. Кто хочет, рано или поздно сможет это. Ну а нам-то это нафиг нужно? Мы-то уже научились генерировать активные объекты в ответ на запрос пользователя, в которых уже заложено не только то, что пользователю надо сей секунд, но и то, что ему потребуется в следующий момент. Осталось сделать один логический шаг в духе WebLink - отдавать описание (HTML-страницу), а уж пускай ее интерпретирует кто-то другой так, как сумеет. Если объект предназначен для интерпретации в родной среде - очень хорошо, мы это сделаем оптимально, если в чужой - мы в силах облегчить дальнейшее взаимодействие с нами же. Что потребуется - протокол некий потребуется. Свой-Свой, Свой-Чужой, Чужой-свой. С первым (С-С) - нет проблем, какой захотим, такой и будет. Второй - придется что-то знать о этом чужом. Например, для HTML знаем, что это за протокол. Наконец, третий - это он о нас должен что-то знать. А мы ему подпихнем не только протокол, но и модуль, его реализующий, в виде специализированного ActiveX'а, например. Если подумать, то можно иметь один общий логический стандарт + возможность быстрого перекладывания этого логического стандарта для конкретного чужака - не так уж их много и будет. А для разработчика будет все едино! Тогда мы сможем разрабатывать приложение в привычной для нас среде Workstation, а исполнять на чем-нибудь другом. Все так делают, и очень довольны - мы создаем HTML-страницу в редакторе (или вообще генерим на ходу), а исполняем в браузере.