OberonCore

Буквально недавно я думал, что разобрался с тем как строятся компоненты.
Но реально начав писать их я понял, что ровным счетом ничего не понял и надо начинать с начала. Хэлп я уже читал, но по нему трудно понять как правильно строятся компоненты.

На данный момент много вопросов, но буду задавать постепенно. Надеюсь кто-нибудь ответит.

Назначение абстрактных записей? Как на их основе строить каркас? И как этот каркас можно использовать?

Абстрактная запись - это базовый тип, который имеет только интерфейс, но не имеет реализации. Что это нам дает? Давайте на примере. Создаем модуль для работы с файлами в нашем каркасе, как это сделано в ББ:

А где реализация? Реализации нет и в этом модуле и не будет. Клиентские модули будут работать, естественно, с переменными каких-то конкретных типов-потомков, но даже не будут подозревать об этом. Более того, в зависимости от ситуации можно им подсовывать экземляры разных типов. Но как клиентскому модулю получить экземпляр конкретного типа, ничего не зная о нем? Для этого используется известный в ООП механизм фабрик типа, которые в ББ называются директории.
Объявляется опять же асбтрактный тип, через интерфейс которого клиенты могут создавать экземпляры других типов модуля:

И финальный штрих - объявим экспортированную переменную-указатель на фабрику:

Все, интерфейс для клиентов закончен, больше клиентам ничего знать не надо. Они могут создавать файлы через обращение Files.dir.New(...).
Теперь плавно переходим к реализации. Финальный шрих нашего модуля Files:


Все. Каркас для файлов готов.

Теперь пишем модуль реализации:

Наш модуль будет прилинкован сразу после Kernel и должен будет о себе "заявить", подставив при своей загрузке свою фабрику HostFiles.Directory в Files:


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

Дальше начинается самое интересное. Обычной файловой системы нам мало. В ББ есть возможность припаковывать файлы к EXE, создавая своего рода виртуальную файловую систему внутри приложения. Как нам обеспечить прозрачную работу с ней? Да проще пареной репы

Делается еще один модуль HostPackedFiles, в котором реализуются File/Locator/Directory для работы с упакованными файлами.
В нем объявляется следующие процедуры:

Откуда-нибудь, например, из конфигурационного файла Config, вызываем HostPackedFiles.SetFilesDir. В Files инсталлируется новая директория.
Это директория сама решает, относится ли запрошенный файл к упакованной файловой системе или к реальной. В первом случае клиенту возвращается HostPackedFiles.File, во втором - HostFiles.File, c которыми клиент работает совершенно одинаково и даже не подозревает о хитрых манипуляциях. Потом можно отключить HostPackedFiles, если будет желание.

А захотим сделать прозрачный доступ к FTP через Files - да сколько угодно.
У меня, например, есть модуль, позволяющий работать с шифрованными файлами. Щелкаешь на коммандер - и все сохраняемые файлы начинают шифроваться, а при загрузке - расшифровываться. Щелкаешь на другой - работа с шифрованием отключается.

Спасибо. Кое что началось прояснятся.

1. А в чем смысл в таком определении:

TYPE MyRec = POINTER TO ABSTRACT RECORD END;

И в таком:

TYPE MyRec = ABSTRACT RECORD END;

То что первая, это указатель на запись это понятно.
Но не понятен смысл такого определения.

2. Когда описываешь метод записи TYPE MyRec = EXTENSIBLE RECORD END;
нада писать PROCEDURE (VAR m: MyRec) ......
А когда описываешь метод указателя на запись: TYPE MyRec = POINTER TO EXTENSIBLE RECORD END;
надо писать PROCEDURE (m: MyRec) ......
Иначе компилятор ругается.

3. И наконец
Чем такое:

TYPE MyRec = ABSTRACT RECORD
MyProp-:INTEGER;
END;
PROCEDURE (VAR m: MyRec) MyProc* (), NEW, ABSTRACT;

Отличается от такого:

TYPE MyRec = EXTENSIBLE RECORD
MyProp-:INTEGER;
END;
PROCEDURE (VAR m: MyRec) MyProc*(), NEW, EMPTY;

PS: Иногда кажется вот, наконец, понял компонентный паскаль, а потом оказывается, что ничего и не понял.

Да, документация устроена дурно - найти нужные вещи трудно. Тем не менее эти нюансы КП описаны - можно посмотреть раздел "Что нового в языке?".
TYPE MyRec = POINTER TO RECORD END
это все равно, что объявить:

Однако тогда у пользователя останется возможность использовать тип и статически, что очень часто нежелательно. В частности, указатели мы можем выдавать пользователю "контролируемо", проводя нужную инициализацию. При создании через NEW память обнуляется, при создании в стеке VAR r: MyRecDesc будут обнулены только поля-указатели. В общем, есть веские причины делать некоторые типы только динамическими. Тогда не вводят статический тип вообще, а пишут единственное объявление POINTER TO ABSTRACT RECORD ...

Self-параметр метода должен передаваться либо по ссылке (VAR r: MyRecDesc), либо через указатель (r: MyRec) . Для динамических типов, ясно, можно объявлять методы только вторым способом. А вот для статических типов можно объявить как VAR-методы, так и POINTER-методы. Первые методы можно будет вызывать для любого экземпляра типа - как статического, так и динамического - ведь указатели, передаваемые параметром, неявно разыменовываются.
А вот вторые можно будет вызывать только через указатель, то есть, только для переменных в куче (в КП указатель может указывать только на объект в куче).

Теперь об ABSTRACT. Этот модификатор запрещает создавать любые экземпляры типа. Т.е. от типа можно только наследоваться. Единственное его назначение - описывать базовый интерфейс семейства типов.
Для ASBTRACT-записи некоторые процедуры можно реализовать, а можно оставить нереализованными, пометив их также ABSTRACT.

EXTENSIBLE же говорит, что тип может быть расширен в дальнейшем. Но он может использоваться и сам по себе. ABSTRACT-методов у не-ABSTRACT типа быть не может. А вот EMPTY - пожалуйста. Это будет заглушка, которая при вызове ничего не будет делать. Зато в расширенных типах ее можно переопределить, как и EXTENSIBLE.
EMPTY равносильно тому, что написать:
PROCEDURE (t: Type) Proc, EXTENSIBLE;
END;

А у абстрактных типов абстрактными помечают те процедуры, которые расширенный тип (если он тоже не абстрактный) обязан реализовать, иначе компилятор скажет об ошибке. Например, у Views.View метод Restore - абстрактный, и любое отображение обязано его реализовать. А все другие расширяемые методы - либо EXTENSIBLE, либо EMPTY. Мы можем их и не реализовывать.

Вопрос по предыдущему Вашему сообщению:

А как сделать что бы программа переключалась между низкоуровневыми модулями реализующими абстрактные типы в Files?
Например, между HostFiles и HostPackedFile или HostFTPFile?

Что бы пользователь, например, вводил только путь(может url), а программа определяла, что это и выбирала разными реализациями.

Последняя из установленных Directory при запросе к ней, например, dir.New("ftp://..") сама решает, может (и хочет ли) она отработать такой запрос. Если нет, то передает вызов ниже, другой директории и возвращает File другого, не своего, типа.

Спасибо. Многое стало ясно.

И ещё.

Вы писали примерно такое:



Получается низкоуровневые модули иницилизируют модули верхнего уровня, а не наоборот?
BB вызывает все модули у которых есть:

BEGIN
Процедура инициализации();
END Модуль.

Так?

Если так, то например как BB поймет, когда я линкую EXE, где у меня находится ГЛАВНЫЙ МОДУЛЬ который тоже имеет:

BEGIN
Тело программы.
END ГлавныйМодуль.

Будет не хорошо, если главный модуль выполнится раньше чем инициализируются данные.

Никак не поймёт, Вы это должны будете сами ему явно указать.

Еще раз посоветую Вам до конца прочесть тему:
http://blackbox.metasystems.ru/forum/vi ... .php?t=132

Там вопросы линковки/загрузки/инициализации подробно обсуждались.

Хотелось бы ещё узнать:

Вот такой, трах тибидох, будет работать?

В одном модуле создаем каркас.

TYPE Человек = POINTER TO ABSTRACT RECORD; END;
Мужчина = POINTER TO ABSTRACT RECORD(Человек); END;
Женщина = POINTER TO ABSTRACT RECORD(Человек); END;

PROCEDURE (h: Человек) Оболванить* (ch: Человек), NEW, ABSTRACT;

Ну соответственно человека, мужчину и женщину реализовываем в другом модуле. А потом в нем же:

VAR Чел: Человек;
Муж: Мужчина;
Жен: Женщина;

BEGIN
(* Куралесим с Муж и Жен. А потом *)
Чел.Оболванить(Муж);
Чел.Оболванить(Жен);
END;

Извиняйте, если ерунду спрашиваю.

Да, работать будет. Будет вызываться метод того типа, на который фактически указывает переменная. Т.е. в Вашем коде можно переменной Чел присвоить указатель на мужчину/женщину/нечто другое. И будет вызываться тот метод, который для того типа реализован.

Кстати, современная медицина способна превратить мужчину в женщину, а женщину в мужчину. Так что типов "Мужчина" и "Женщина" как расширений типа "Человек" - нету, ведь тип уже созданного объекта поменять нельзя, а пол уже созданного человека - можно.

Нуууу. Медицина много чего может.

А можно обратиться через тип человек к типу мужчина в методе Оболванить?

PROCEDURE (c: Человек) Оболванить* (ch: Человек);
BEGIN
ch(Мужчина).Поесть();
END Оболванить;

Или так нельзя?

Да, можно.

Все-таки я не очень понял, как осуществдяется "подмена". Только при загрузке модуля заменой фабрики?
А если нужно в каком-то модуле обеспечить независимую от конкретного типа обработку объектов? Т.е. этот модуль "знает" только абстрактные типы, а объекты к нему сыплются конкретные. Он вызывает метод абстрактного типа, а конкретный объект как сам должен определить, что именно ему нужно работать?

Не уверен, что понял Ваш вопрос,
но то, о чём Вы спрашиваете, называется виртуализация вызова (динамическое связывание вызова).
Это общий механизм всех объектно-ориентированных языков.

НЕвиртуальный вызов:
t.Do для случая, если переменная t имеет нерасширяемый тип (просто RECORD). Компилятор генерирует машинный код вида ВЫЗВАТЬ ПРОЦЕДУРУ (АДРЕС ПРОЦЕДУРЫ Do в модуле, где тип объявлен t)

Виртуальный вызов:
t.Do, если переменная t имеет EXTENSIBLE или ABSTRACT-тип.
Комплятор генерирует код вида:
- от объекта t пойти к описателю его типа;
- у описателя типа есть таблица процедур типа, взять там реальный адрес процедуры Do для реального типа объекта t;
- вызвать процедуру по этому полученному реальному адресу процедуры.

Так вызов и попадает сразу на нужную процедуру, в зависимости от фактического типа объекта, на который указывает t (и независимо от того, что сама переменная t имеет базовый, абстрактный тип).

Спасибо! Да, я примерно так и представлял. Непонятно вот что: есть модуль, в котором описаны абстрактные типы, они экспортируются, в т.ч. их абстрактные методы:
TYPE Rec*=POINTER TO ABSTRACT RECORD END;
TYPE RecSet*=POINTER TO RECORD
r*:POINTER TO ARRAY OF Rec;
END;
PROCEDURE (r:Rec) Do* (), NEW, ABSTRACT;

В других модулях реализуем их, но не экспортируем.
Еще один модуль реализует работу (например, математику) со списком объектов, которые являются наследниками абстрактного типа, но они могут быть разными его реализациями (он импортирует первый модуль):
PROCEDURE DoMath* (rs:RecSet);
VAR i:INTEGER;
BEGIN
FOR i:=0 TO LEN(r)-1 DO
rs.r[i].Do;
END;
END DoMath;
(предполагаем, что rs где-то заполнился конкретными r разных типов)
Это будет работать? Или я что-то неправильно делаю, с т.з. архитектуры?

Если Вас смущает именно момент "в других модулях реализуем, но не экспортируем", то это всего лишь синтаксическая условность.

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

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

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

У Вас, вроде, всё нормально. Архитектурно смущает открытость поля r (т.е. данные доступны кому угодно не через методы), но для каких-нибудь конкретных вычислительных задач, где не хочется громоздить и терять производительность на оборачивании всех-всех данных в методы, можно и так.

Это просто абстрактный пример, я не стал его "окультуривать". На самом деле, у меня записи добавляются клонированием прототипа:
PROCEDURE (rs:RecSet) Add* (VAR prototype:Rec);
PROCEDURE (r:Rec) Clone* ():Rec;

Меня смущает, что модуль (назовем его Math) и его методы (DoMath) работают с указателями на абстрактный Rec, "не зная" о конкретных типах. Т.е. каким-то образом экземпляры Rec, на самом деле имеющие типы OneRec, TwoRec, и т.д. должны вызвать именно свой метод Do, и сделать это в момент выполнения. Есть сомнения, что я правильно организую работу. Что-то здесь не так...

С виду, все вы верно делаете. Работая с абстрактным объектами, ваш модуль будет знать конкретный тип объектов и вызывать соответствующие методы. Также вы можете еще уточнять алгоритм в зависимости от типа реализации с помощью WITH.

В BlackBox у каждой записи или массива есть тег, в котором содержится дополнительная информация, в том числе, по-видимому, и необходимая для реализации таких механизмов. Этот тег очень важен и для автоматической сборки мусора. А возможно в массиве абстрактных переменных реально уже будут хранится указатели на объекты из реализаций, а различные ограничения на соответствие типов проверяются в момент компиляции... Было бы интересно выяснить точно как это реализовано.