OberonCore
https://forum.oberoncore.ru/

Активные структуры данных
https://forum.oberoncore.ru/viewtopic.php?f=6&t=975
Страница 2 из 3

Автор:  Trurl [ Среда, 07 Май, 2008 13:57 ]
Заголовок сообщения:  Re: Активные структуры данных

Код:
MESSAGE
      NewFuncMsg (VAR error: INTEGER);
      FuncNameMsg (name: Name; VAR error: INTEGER);
      NewSentMsg (VAR error: INTEGER);
      BeginExprMsg (VAR error: INTEGER);
      EndExprMsg (VAR error: INTEGER);
      CharMsg (char: CHAR; encode: BOOLEAN; VAR error: INTEGER);
      CharVarMsg (symTab: Structs.SymTab; name: Name; VAR error: INTEGER);
      FreeVarMsg (symTab: Structs.SymTab; name: Name; VAR error: INTEGER);
      NewCondMsg (VAR error: INTEGER);

 TYPE
      ConditionDesc* = RECORD (Structs.Expr)
         predicate*: Name;
         expect*: BOOLEAN
      END;

      Condition* = OBJECT BASED ON ConditionDesc;
      Template* = OBJECT BASED ON Structs.Expr;
      Program* = OBJECT BASED ON Structs.Expr;


METHOD CharMsg (char: CHAR; encode: BOOLEAN; VAR error: INTEGER) -> t: Template;
      VAR c: Char;
   BEGIN
         NEW(c); c.c := char; c.encode := encode;
         t.Insert(c, t.last)
   END CharMsg;

METHOD CharVarMsg (symTab: Structs.SymTab; name: Name; VAR error: INTEGER)-> t: Template;
   VAR lastVar: ANYPTR;
            var: CharVar;
            ref: VarRef;
   BEGIN
         lastVar := symTab.Look(name);
         IF ~ ((lastVar = NIL) OR (lastVar IS CharVar)) THEN
            error := sameNameForDifVars
         ELSIF lastVar = NIL THEN
            NEW(var);
            var.name := name;
            symTab.Add(name, var);
            t.Insert(var, t.last)
         ELSE
            NEW(ref); ref.var := lastVar(Variable);
            t.Insert(ref, t.last)
         END
   END CharVarMsg;



METHOD CharMsg (char: CHAR; encode: BOOLEAN; VAR error: INTEGER) -> c: Condition;
   BEGIN
         CASE char OF
         | 'T': c.expect := TRUE
         | 'F': c.expect := FALSE
         END
   END CharMsg;

METHOD CharVarMsg (symTab: Structs.SymTab; name: Name; VAR error: INTEGER)-> c: Condition;
   VAR lastVar: ANYPTR;
            ref: VarRef;
   BEGIN
         lastVar := symTab.Look(name);
         IF ~( (lastVar # NIL) & (lastVar IS CharVar) ) THEN
            error := unknownVariable
         ELSE
            NEW(ref); ref.var := lastVar(Variable)(CharVar);
            c.Insert(ref, c.last)
         END
   END CharVarMsg;

Автор:  Илья Ермаков [ Среда, 07 Май, 2008 14:03 ]
Заголовок сообщения:  Re: Активные структуры данных

Это выражено на гипотетическом языке, я так понимаю? А какой Вы делаете вывод?

Автор:  Vlad [ Среда, 07 Май, 2008 17:07 ]
Заголовок сообщения:  Re: Активные структуры данных

AVC писал(а):
Вот так мы и общаемся: я говорю Вам, что такой-то системный механизм основан на тождестве интерфейсов обработчиков, а Вы мне отвечаете, что отказ от тождества здорово этот механизм дополнит.


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

Автор:  Vlad [ Среда, 07 Май, 2008 17:23 ]
Заголовок сообщения:  Re: Активные структуры данных

Илья Ермаков писал(а):
Ну-ка пример в студию... Как это можно организовать динамический выбор одного из перегруженных методов по динамическому типу параметра? Двойная диспетчеризация на основе шаблонов - фишка известная, Элджера читали, как же... Статично и неинтересно.


Двойная диспетчеризация она и в Африке двойная диспетчеризация. Чем вам не угодила реализация на шаблонах (помимо страшного кода)? Чем она менее динамична по сравнению с message bus? Правда я не знаю, что там придумал Элджер :) Я когда-то сам такое делал, как раз когда надо было избавиться от статики.

Илья Ермаков писал(а):
К вопросу об интерфейсе и методах, так что, у нас методы уже в интерфейс перестают входить? Сделать их private нельзя... Или я не так понимаю предлагаемое решение.


Хорошо. На пальцах.
C++. Пока метод не светится в *.h, причем в public секции - он не может являться частью интерфейса.
Oberon. Пока методу не поставили * - он не является частью интерфейса.

Если против этих утверждений нет возражений, то объясните что заставит пихать меня конкретные методы-обработчики в *.h? Или хотя бы в public?

Автор:  Vlad [ Среда, 07 Май, 2008 17:32 ]
Заголовок сообщения:  Re: Активные структуры данных

Илья Ермаков писал(а):
Объекту поступило сообщение. Это его внутреннее суверенное дело, чего и как он делает с ним дальше. Есть одна точка на его входе, в которой принимается решение (может быть, сразу же будет разрулено на те же отдельные методы, но уже свои внутренние). Зачем всовывать сторонний внешний механизм, который чего-то ещё до объекта сортирует?


Не до объекта, а с учетом задекларироанных объектом свойств. Это очень удобно для решения целого класса задач. Пример вы сами приводили.

Илья Ермаков писал(а):
"Чиста философски", всю корреспонденцию в полной мере интерпретировать способен только получатель. Так зачем пытаться делать какую-то неполную интерпретацию на его входе? Заставить почтальона разбираться в типах моих писем и раскладывать мне их по ящикам на двери? Так он и знать не должен про эти типы, его дело - доставить....


Я не буду развивать аналогии, это тупиковый путь.

Автор:  Илья Ермаков [ Среда, 07 Май, 2008 18:49 ]
Заголовок сообщения:  Re: Активные структуры данных

Vlad писал(а):
Я не буду развивать аналогии, это тупиковый путь.


Аналогии бывают, конечно, тупиковыми. Но вот если некий механизм на пальцах нельзя проиллюстрировать подобной физически существующей аналогией - то уж точно повод задуматься о его тупиковости. Замутнение простого понятия обмена сообщениями чёрте-чем типа методов и перегрузок... ерунда...

Автор:  Wlad [ Среда, 07 Май, 2008 23:06 ]
Заголовок сообщения:  Re: Активные структуры данных

Vlad писал(а):
Метод это еще не интерфейс.

Пачему?
Даже во многих книшкахЪ (типа той же про AS/400) есть сноски, что " термином API мы будем называть" не только СОВОКУПНОСТЬ функций некоей библиотеки или объекта, но и ОТДЕЛЬНУЮ ФУНКЦИЮ. Так и пишут "fread API, close API"...

В Вашем понятии "метод это еще не интерфейс" просто потому, что вы подспудно мыслите "интерфейс" аки некую совокупность функциональных отрывкофф. Ежели носитель этих "отрывков" не носит состояния - то чем это отличается от "просто библиотеки"? А если носит (что в 99% случаев и подразумевается) то указанная "совокупность" - просто запечатленный набор названий чего-то, что вызывается в некотором порядке (иногда варъируемом). Но это не есть интерфейс - вы вынуждены "взламывать договор-интерфейс" хотя бы описанием и оговором такого порядка. И обычно ДАЛЕКО не формализованным описанием...

Описание интерфейса, как набора функций некоей сущности - бред! Интерфейс - формализованное (строго!) описание последовательности АКТОВ ОБЩЕНИЯ с целью удовлетворения клиентов по какому-либо (заявленному "сервером") поводу.

Автор:  Vlad [ Четверг, 08 Май, 2008 00:34 ]
Заголовок сообщения:  Re: Активные структуры данных

Илья Ермаков писал(а):
Замутнение простого понятия обмена сообщениями чёрте-чем типа методов и перегрузок... ерунда...


Да-да. Старая песня. Зачем нам паттерн-матчинг если можно отбиться if'ами. Зачем нам енумы, если можно отбиться целыми. Зачем нам шаблоны, если можно накопипастить. И т.д.

Автор:  Vlad [ Четверг, 08 Май, 2008 00:40 ]
Заголовок сообщения:  Re: Активные структуры данных

Владимир Лось писал(а):
Описание интерфейса, как набора функций некоей сущности - бред!


Вот видите. И я о том же :) Сама по себе функция (или метод) это еще не интерфейс.

Автор:  Wlad [ Пятница, 09 Май, 2008 10:35 ]
Заголовок сообщения:  Re: Активные структуры данных

Vlad писал(а):
Владимир Лось писал(а):
Описание интерфейса, как набора функций некоей сущности - бред!

Вот видите. И я о том же :) Сама по себе функция (или метод) это еще не интерфейс.

ЧТо я должен видеть? Или высказывайтесь точнее по понятиям, котры озвучиваете или определите своим набором слов, о чём говорите.

Автор:  Vlad [ Пятница, 09 Май, 2008 18:36 ]
Заголовок сообщения:  Re: Активные структуры данных

Владимир Лось писал(а):
ЧТо я должен видеть? Или высказывайтесь точнее по понятиям, котры озвучиваете или определите своим набором слов, о чём говорите.


Вот это ваша цитата?
Цитата:
Интерфейс - формализованное (строго!) описание последовательности АКТОВ ОБЩЕНИЯ с целью удовлетворения клиентов по какому-либо (заявленному "сервером") поводу.


Здесь есть что-то про методы? Метод становится интерфейсом, после того, как он "заявлен сервером". Если он не заявлен, то это просто метод.

Автор:  Wlad [ Пятница, 09 Май, 2008 21:46 ]
Заголовок сообщения:  Re: Активные структуры данных

Vlad писал(а):
Метод становится интерфейсом, после того, как он "заявлен сервером". Если он не заявлен, то это просто метод.

А что такое "просто метод"?

Автор:  Vlad [ Пятница, 09 Май, 2008 23:09 ]
Заголовок сообщения:  Re: Активные структуры данных

Владимир Лось писал(а):
А что такое "просто метод"?


Э... Ну например как в C++ есть просто методы :) В ББ есть связанные процедуры.

Автор:  Wlad [ Воскресенье, 11 Май, 2008 10:33 ]
Заголовок сообщения:  Re: Активные структуры данных

Vlad писал(а):
Э...

Хорошо. Задам вопрос по-другому: а что такое "НЕ просто методы"?

Автор:  Vlad [ Понедельник, 12 Май, 2008 20:09 ]
Заголовок сообщения:  Re: Активные структуры данных

Владимир Лось писал(а):
Vlad писал(а):
Э...

Хорошо. Задам вопрос по-другому: а что такое "НЕ просто методы"?


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

Автор:  Vlad [ Понедельник, 12 Май, 2008 20:30 ]
Заголовок сообщения:  Re: Активные структуры данных

AVC писал(а):
Эта схема работает, но обладает рядом недостатков: она несколько сложновата и громоздка (требуется реализовать много методов), требуется также переопределять интерфейсы фигур в случае появления новых классов устройств.
А какую реализацию двойной диспетчеризации имели в виду Вы?


Код:
figure.h:
class Figure {
public:
    virtual void draw(Device &d); // интерфейсный метод
    ...
};

circle.cpp:
class Circle : public Figure
                , handle_draw<Screen,Printer>
{
    virtual void draw(Device &d); // обрабатываем "неизвестные" Device
   
    void draw(Screen &s); // НЕ интерфейсный метод
    void draw(Printer &p); // НЕ интерфейсный метод
};

Автор:  Илья Ермаков [ Понедельник, 12 Май, 2008 21:34 ]
Заголовок сообщения:  Re: Активные структуры данных

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

Вроде бы при двойной передаче связанность двух классов сильнее, чем при шине сообщений. Можно пример?

Автор:  Wlad [ Понедельник, 12 Май, 2008 22:38 ]
Заголовок сообщения:  Re: Активные структуры данных

Vlad писал(а):
Владимир Лось писал(а):
Vlad писал(а):
Э...

Хорошо. Задам вопрос по-другому: а что такое "НЕ просто методы"?

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

Ну теперь вернёмся к первому варианту... Так что же всё-таки такое "просто методы"?

Автор:  Vlad [ Вторник, 13 Май, 2008 00:54 ]
Заголовок сообщения:  Re: Активные структуры данных

Владимир Лось писал(а):
Ну теперь вернёмся к первому варианту... Так что же всё-таки такое "просто методы"?


Это методы, не фигурирующие в интерфейсе (не заявленные "сервером" и не потреблямые "клиентами").

Автор:  Vlad [ Вторник, 13 Май, 2008 01:00 ]
Заголовок сообщения:  Re: Активные структуры данных

Илья Ермаков писал(а):
Может, я к вечеру туго соображаю...
Но что-то шину сообщений на двойной передаче сэмулировать не могу.


А зачем ее эмулировать? С тем же успехом вы можете пытаться эмулировать if/else с помощью switch/case. Или целые с помощью енумов. Двойная диспетчеризация более высокоуровневый (и более ограниченный) механизм.

Страница 2 из 3 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/