OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Четверг, 28 Март, 2024 17:40

Часовой пояс: UTC + 3 часа




Начать новую тему Ответить на тему  [ Сообщений: 179 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7, 8, 9  След.
Автор Сообщение
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 16 Декабрь, 2010 17:03 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Galkov писал(а):
Но в упор не вижу вновь созданных динамических объектов. И где Вы их увидели - не пойму...


Давайте ещё раз и по пунктам.

Есть у меня PROCEDURE OF OBJECT.
Она служит для вызова МЕТОДА какого-то ОБЪЕКТА.
Т.е. это указание на "какого объекта" и на "какой метод".

Обычная процедурная переменная плюс обычный указатель на объект.

Где Вы видели в безопасных языках "обычный указатель" на объект не в куче?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 16 Декабрь, 2010 18:15 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Один из принципов, соблюдаемых в Обероне, - нужные сложные типы определяются явно, для этого используют RECORD.
Например, для создания каких-то абстрактных типов с ограничениями вроде Скорость, Высота и проч. Самый универсальный способ - перенести эту логику на программиста и его абстрактные типы данных, а не пытаться засунуть спец. типы в компилятор.

Делегаты - это один из видов параметризации поведением.

Что мне мешает принимать в параметризуемом куске некий абстрактный Handler с одним методом нужного вида (может быть самого общего - HandleMsg), а тому, кто параметризует, сделать нужную реализацию этого типа и метода (например, в виде обёртки с обращением к какому-то оборачиваемому объекту)? Это будет единообразный и универсальный способ.

Мне должна помешать боязнь лишнего вызова процедур? А меня в обычном случае (если это не высоконагруженный модуль) не пугают заранее известные слагаемые и даже небольшие множители (1,5-2 обычно не заслуживают внимания). Детерминировано, заранее известно - и нормально.
Не надо переносить узкоспециализированные боязни и следующие из них оптимизации из микроконтроллерных систем в область универсальную.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 16 Декабрь, 2010 19:19 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Реализация procedure of object основывается на том факте, что все class'ы Delphi унаследованы (явно или неявно) от базового TObject (который может быть размещён только в динамической памяти). Другими словами, в процедуру передаётся скрытый параметр Self: TObject.

В КП есть общий базовый тип ANYREC и соответствующий указатель ANYPTR.

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

В остальном всё реализуется аналогично. Единственное отличие - чуть меньше синтаксического сахара, зато больше явно прописанных преобразований типов и передаваемых параметров.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 16 Декабрь, 2010 22:42 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Александр, я не совсем понимаю, что Вы имеете в виду под "Реализация procedure of object основывается на том факте, что все class'ы Delphi унаследованы (явно или неявно) от базового TObject". Как это связано?

Технически, если я вызываю делегат, то мне нужно в точке вызова знать два адреса: адрес метода (возможно, просто его номер в вирт. таблице, неважно) и адрес экземпляра объекта. Который пойдёт как Self вызываемому методу.

Где я не прав и что здесь даёт наличие общего предка?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Пятница, 17 Декабрь, 2010 06:20 
Аватара пользователя

Зарегистрирован: Вторник, 19 Сентябрь, 2006 21:54
Сообщения: 2449
Откуда: Россия, Томск
Илья Ермаков писал(а):
Где я не прав и что здесь даёт наличие общего предка?
Вы во всём правы, это я стромозил. Подумал, что объекты разного типа настолько сильно могут различаться. Это, конечно, возможно только при связывании разнородных рантаймов в общий код.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Пятница, 17 Декабрь, 2010 12:05 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Илья Ермаков писал(а):
Один из принципов, соблюдаемых в Обероне, - нужные сложные типы определяются явно, для этого используют RECORD.
Например, для создания каких-то абстрактных типов с ограничениями вроде Скорость, Высота и проч. Самый универсальный способ - перенести эту логику на программиста и его абстрактные типы данных, а не пытаться засунуть спец. типы в компилятор
Илья Евгеньевич, я же кажется Вам уже объяснял, что никакими run-time действиями Вы не воспроизведете полную эквивалентность (скажем, совместимость по присваиванию) только по сигнатуре метода, независимо от типа объекта, к которому применяется метод.
Убедительная просьба - перечитайте еще раз, но не "по-диагонали"
Это было бы тем более правильно, чем громогласнее "тезисы" Вы декларируете.
Илья Ермаков писал(а):
два адреса: адрес метода (возможно, просто его номер в вирт. таблице, неважно) и адрес экземпляра объекта
Вообще-то, важно. Между ранним связыванием и поздним - есть разница. Также существует разница между проверками на соответствие типов в run-time, и compile-time. И проявляется эта разница и на надежности программирования, а не только на эффективности.

Блин, даже до апологетов C++ сей замечательный факт уже дошел, но не до Вас.
Не могут они воспроизвести эту функциональность. А вот Илья Евгеньевич - может, оказывается.
Потому-что ему пофиг, когда производятся проверки и связывание в run-time, или в compile-time.
Причем, свято уверен, что основная фишка Оберонов.

В начале топика, я может быть и поверил бы (и как следствие - послал бы этот Оберон куда подальше), но сейчас я вижу другое - Вы слишком много на себя берете, когда вещаете с броневичка, что нужно программистскому сообществу вообще, и Обероновскому (как я недавно выяснил) - в частности.

==================================================================
А теперь я Вам дам урок по Окамму. Потому как вижу - ни хрена Вы в нем не понимаете.
Не вводить новых сущностей - ДА, Вы не нарушите принцип Окамма.
Вы действительно не введете новую сущность без необходимости. Но, регулярно так поступая, вы соблюдаете не вовсе принцип Окамма, а принцип религиозной секты.
Вся разница в последних двух словах: БЕЗ НЕОБХОДИМОСТИ.
Что означает следующее: перед отвержением новой сущности мы показываем отсутствие этой самой необходимости.
Что требует несколько большего ума.
Если Вы отвергаете некую сущность, которая ведет к лучшему пониманию кода человеком, значит Вы поддерживаете язык, в котором это не является необходимостью.
Настолько воинственно, что позволяете себе некорректные высказывания в адрес той части Оберон-сообщества, которая эту необходимость (понимаемость человеком) признает.

Урок окончен.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Пятница, 17 Декабрь, 2010 12:42 
Модератор
Аватара пользователя

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Galkov писал(а):
...но сейчас я вижу другое - Вы слишком много на себя берете, когда вещаете с броневичка...
И тут подъехал второй броневичёк [уточнение: на нём приехал тов. Galkov]...

Есть настоятельно предложение от администрации ездокам (Илья Ермаков и Galkov) --- продолжить общение ЛС.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Пятница, 17 Декабрь, 2010 12:50 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Вот я уже два раза предлагал Илье показать код, альтернативный приведенному из ActiveReport
А он вместо этого вопросы всякие задает.
Ответы на которые были бы сразу ясны методом показывания пальцем.
Сколько и каких провакационных объектов в хипе? Да вот они. Ровно столько же... Ну и так далее

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Пятница, 17 Декабрь, 2010 13:17 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Вот Вам пример. Именно так я и делаю в таких случаях. И меня всё устраивает.

Код:
Пусть дан модуль Buttons с таким интерфейсом:

DEFINITION Buttons;

   IMPORT Views;

   TYPE
      Handler = POINTER TO ABSTRACT RECORD
         (h: Handler) Do-, NEW, ABSTRACT
      END;

   PROCEDURE New (IN caption: ARRAY OF CHAR; handler: Handler): Views.View;

END Buttons.

Пусть дан модуль Players с таким интерфейсом:
DEFINITION Players;

   TYPE
      Player = POINTER TO ABSTRACT RECORD
         (p: Player) Play, NEW, ABSTRACT;
         (p: Player) Stop, NEW, ABSTRACT
      END;

   PROCEDURE New (IN mediaFile: ARRAY OF CHAR): Player;

END Players.

Тогда я сделаю панель из двух кнопок и свяжу её с плеером так:

MODULE MyApplication;

   IMPORT Views, Buttons, Players;

   TYPE
      PlayHandler = POINTER TO RECORD (Buttons.Handler) pl: Player END;
      StopHandler = POINTER TO RECORD (Buttons.Handler) pl: Player END;

   PROCEDURE (h: PlayHandler) Do;
   BEGIN
      h.pl.Play
   END Do;
   
   PROCEDURE (h: StopHandler) Do;
   BEGIN
      h.pl.Stop
   END Do;

   PROCEDURE OpenPlayerDesk* (IN mediaFile: ARRAY OF CHAR);
      VAR pl: Players.Player;
         ph: PlayHandler;
         sh: StopHandler;
         pb, sb: Views.View;
   BEGIN
      pl := Players.New(mediaFile);
      NEW(ph); ph.pl := pl;
      NEW(sh); sh.pl := pl;
      pb := Buttons.New("Play", ph);
      sb := Buttons.New("Stop", sh);
      (* ... Выкладываем куда-нибудь кнопки pb и sb ... *)
   END OpenPlayerDesk;

END MyApplication.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Пятница, 17 Декабрь, 2010 13:24 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Резюме по примеру:
1) Особенность: делегирующий слой объявляется явно и типизированно (под конкретную задачу делегирования).
2) Типа-недостаток: многословнее.
3) Не-типа-а-реально-преимущество: слой делегирования явный и может содержать любую посредническую логику. Более того, он даже приглашает нас при развитии приложения расширяться в этом месте. В то время, как ваши procedure of object напрямую "сваривают" вызов и вообще не предполагают посреднического слоя. А посредничество, расслоение лежит, так или иначе, в основе всех компонентных паттернов. Нужна расширяемость - закладывается косвенность.
4) Концептуально: Оберон предполагает сущности, к которыми можно обращаться, двух видов: процедура и запись, имеющая интерфейс. Статический интерфейс. И два вида ссылок - на процедуры и на записи. "Разламывание" интерфейса на отдельные операции и независимая идентификация операций не предполагается. Такое "разламывание" можно рассматривать только как оптимизацию, "сахар" или "хак" для каких-то частных случаев.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Суббота, 18 Декабрь, 2010 15:04 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Илья Ермаков писал(а):
1) Особенность: делегирующий слой объявляется явно и типизировано (под конкретную задачу делегирования).
Ну вот видите :)
Так кто кого провоцирует на использование хипа не по делу ???
Ну не создавали на AO дополнительных объектов в хипе.
Типа наводящий вопрос: не припомните, кто громче всех кричит "Держи вора!!!"

Илья Ермаков писал(а):
2) Типа-недостаток: многословнее
Типа впечатлен деликатностью характеристики :)
А я скажу чего думаю: разработчику приходится в памяти держать вдвое больше абстракций.
Пока их три-шесть - ничего страшного. А когда их 20-40 - у каждого же существует свой предел для надежной работы... На HiAsm, 20 элементов - это еще простенькая схемка, типа для новичков... И сотню рисуют без структурирования - физические размеры экрана ограничивают в большей части.
Справедливости ради: тут и визуальность свое дело делает, наверное.


Илья Ермаков писал(а):
3) Не-типа-а-реально-преимущество: слой делегирования явный и может содержать любую посредническую логику. Более того, он даже приглашает нас при развитии приложения расширяться в этом месте. В то время, как ваши procedure of object напрямую "сваривают" вызов и вообще не предполагают посреднического слоя.
Вы не правы - еще как предполагает. И опять же, без создания новых сущностей. И я уже это пытался изложить
Посредническая логика просто располагается в просто-процедуре, находящейся в контексте видимости объектов-агрегатов. Или методе синглетона - кому как больше нравится.
И все. В этом случае, "разъемным соединением" может служить старый добрый процедурный тип. Если бы не одна незадача: потом нам захочется клонировать все это безобразие, для создания некой метасистемы.

И ведь что занимательно: в подходе от AO для этого делать не надо практически НИЧЕГО. Перечитайте-ка цитату из Мюллера. Процедурный тип и procedure of object - это одно и то же. Хочешь установить в него посредническую просто-прцедуру - хоть сто порций. Выделил все это в определение объекта - все снова в теме. Даже определение объекта в стиле Явы к месту оказывается: процедура автоматически становится методом, а "разъем" и ее прекрасно принимает, без рихтовки напильником. Все происходит безвозмездно, то есть - даром :P

У меня не поставлена техника получать результаты из названия фамилий и должностей - уж извините. Просто смотрю, и вижу - все в тему. Пока-что....

Количество косвенных вызовов/обращений, разницу между ранним/поздним связыванием - считать не будем, надеюсь. В виду очевидности вопроса.

Илья Ермаков писал(а):
4) Концептуально: Оберон предполагает сущности, к которыми можно обращаться, двух видов: процедура и запись, имеющая интерфейс. Статический интерфейс. И два вида ссылок - на процедуры и на записи. "Разламывание" интерфейса на отдельные операции и независимая идентификация операций не предполагается. Такое "разламывание" можно рассматривать только как оптимизацию, "сахар" или "хак" для каких-то частных случаев.
Вынужден не согласиться по двум позициям:
  1. Мне уже известно, что не весь Оберон. Гуткнехт - это вроде тоже Оберон
  2. Не уверен, что именно моя позиция является "каким-то узкоспециализированным частным случаем". Поставьте себя хоть на секунду на место QT-шников: они не перешли еще барьер отхода от майнстрима, и скольких седых волос им могло стоить тогда введение слотов/сигналов. Но они это сделали, наступили на горло собственной же песне, что "C++ это рулез". Про дельфян и говорить нечего. Но и Активный Оберон - мой единомышленник, оказывается. Получается как раз наоборот - только баба-яга и против :)

======================================================================================
Концептуально: громкие слова потрясают воздух, но не собеседника. Конкретный код ставит все на свои места.
Имеющий глаза - да увидит.
Те, кто привык черное называть белым (или каким-то другим цветом в зависимости от политической ситуации) - увидит одно. Кто не привык - другое, наверное.
Главное, что у каждого есть возможность увидеть правду.

В общем: "развалинами Рейхстага - удовлетворен" :D


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Суббота, 18 Декабрь, 2010 17:10 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Хорошо. Поигрались с вырожденным случаем.

Пусть у плеера процедуры Play и Stop имеют параметры. А кнопка по-прежнему принимает в качестве обработчика делегат без параметров.

Придётся развлекаться - объявлять класс-адаптер. Точно такой же, какой у меня есть с самого начала.

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

А в большинстве интересных случаев (не говоря про интеграцию разных компонент) у вас будет такое несоответствие сигнатур. Предупредил же выше: лишний уровень косвенности (нелюбимого Вами позднего связывания) - основной приём в компонентных архитектурах. Умело закладывать его надо по всем слоям системы, а не избегать.
Можно протянуть провод и через вентиляционный канал. Но лучше заранее проложить для него отдельный короб.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Суббота, 18 Декабрь, 2010 17:17 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Между прочим, если приплетать "высокие принципы"...

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

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Суббота, 18 Декабрь, 2010 17:30 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Илья Ермаков писал(а):
Пусть у плеера процедуры Play и Stop имеют параметры
Да ничем не отличатся.
Все, что Вы пишете в методе Do делегата, а напишу в просто процедуре

Илья Ермаков писал(а):
подсистемы не имеют права знать ту структуру связей, в которую они включены
Они и не знают.
При мета-переходе просто-процедуры становятся методами клонируемого объекта. А они имеют полное суверенное право знать все о всех внутренних связях SELF-а


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Суббота, 18 Декабрь, 2010 20:27 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Galkov писал(а):
Все, что Вы пишете в методе Do делегата, а напишу в просто процедуре


Хотите сказать, что объявите процедуру с первым параметром-объектом? Так можно? (технически понял, как; но позволяет ли це Борланд).

Но уже яснее признались :) По крайней мере, очевидно, что Вы будете иметь то же самое ручное объявление посредника.
Ну и чего жаловаться, что в каком-то языке Вам не сделали мелкого дополнительного удобства, позволяющего обойтись в удачном случае не типом, а только процедурой.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Суббота, 18 Декабрь, 2010 20:31 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Но вообще, в общем по теме. Неясно, каковы Ваши конкретные предложения, к кому они направлены и изменений в каком предмете касаются.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Воскресенье, 19 Декабрь, 2010 10:51 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Илья Ермаков писал(а):
Хотите сказать, что объявите процедуру с первым параметром-объектом? Так можно? (технически понял, как; но позволяет ли це Борланд).

Но уже яснее признались :) По крайней мере, очевидно, что Вы будете иметь то же самое ручное объявление посредника
Ну никак я Вас не пойму, Илья
В чем я признался... Какой такой павлин-мавлин...
Вот спарашивается, где в таком расширении "активного" кода Вы увидели "ручное объявление посредника":
Код:
(* агрегаты системы *)
VAR b0, b1, b2: Button; e0: EditBox; p0: MediaPlayer;

(* межагрегатные связи системы *)
PROCEDURE Link000
BEGIN
  p0.Play(e0.GetText);
END Link000;

(* методы системы *)
PROCEDURE Init*(p: MediaPlayer);
BEGIN
(* Reboot -> call system reboot function *)
  p0 := p;
  NEW(b0, "Reboot", System.Reboot);
  NEW(e0, "<enter movie filename here>", NIL);
  (* MediaPlayer UI: bind buttons with player instance *)
  NEW(b1, "Play", Link000);
  NEW(b2, "Stop", p0.Stop);
END Init;

Что же это Вы все время пытаетесь новые сущности придумать, да еще и мне таковое желание приписать...
Где же то самое "чувство принципа Калашникова, заложенное в рефлексы" :D


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

Но поскольку, как минимум я, Разработчиком таки являюсь, практические шаги, можно было бы и сформулировать.
Если Вам это интересно, Илья Евгеньевич, то их можно было бы где-то и изложить. Как только с мыслями соберусь...


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Воскресенье, 19 Декабрь, 2010 13:08 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Вооо. Я тут как раз проснулся с мыслью, что своим обещанием обойтись процедурой-посредником Вы немного поспешили.

Так посмотрите, Вы в своей Link000 обращаетесь к ГЛОБАЛЬНОМУ p0, к глобальному контексту (фактически, просто "откатившись" к процедурной переменной). Я-то думал, можно ли связать чисто динамически... И наткнулся на элементарную проблему - если в качестве делегата воткнута простая процедура, которая уже "адаптирует" вызов и передаёт его дальше объекту, то откуда же она узнает, какому объекту?
Для этого понадобилось бы вводить совместимость методов и процедур вида (object, ...), а потом позволять устанавливать делегат не только присваиванием .. := объект.Метод; но и чем-то типа присваивания пары .. := (объект, обычнаяПроцедура). Такого я не припоминаю ни у Борланда, ни где-то ещё (хотя технически это реализуемо, разумеется).

А аналог Вашего Link000 мы каждый день делаем. Когда кнопке в свойствах указываем имя глобальной процедуры, а она уже по имени получает на неё указатель и им дальше пользуется.
Только интерфейсы в таком случае получаются одноэземплярные, т.е. существует глобально в приложении контекст ровно на один экземпляр интерфейса. В большинстве случаев это даже хорошо. Но для обсуждаемой нами задачи (связывать динамически объекты) это слишком частный случай.

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


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Воскресенье, 19 Декабрь, 2010 13:15 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Galkov писал(а):
Дык все ранее сказанное остается в силе, вроде бы.
[list=1][*]Топик начинался с "неплохо бы добавить"
[*]Признал, что вышестоящее предложение было бы более адекватным на форуме таки Разработчиков
...
Но поскольку, как минимум я, Разработчиком таки являюсь, практические шаги, можно было бы и сформулировать.


Вот, именно это я и ожидал услышать. А теперь попрошу задуматься над таким моим вопросом:
- а чем делегаты лучше-полезней-важнее... исключений... параллелизма в языке... векторно-матричных операций... шаблонов... ? По какому критерию именно их нужно добавить? Может, добавим всё? И куда денется совершенно уникальный язык вместе с "экосистемой" и культурой работы в его базисе?
Давно уже известно: - идя по пути добавления, крайне трудно остановиться, нет критериев. - введя что-то, убрать очень трудно.
- со временем в КП, наверняка, ещё что-то наоборот ужмётся. В плане ООП. Это был виток развития от Оберона, введение средств для построения компонентных каркасов. Виток успешен, обоснован, практичен. Но ещё не проходил через фазу критического упрощения, "экстракта".

Цитата:
Если Вам это интересно, Илья Евгеньевич, то их можно было бы где-то и изложить. Как только с мыслями соберусь...


Как системщику, мне, разумеется, интересна тема реализации тех или иных механизмов. Правда, использовать такие механизмы я привык библиотечно. И позицию относительно КП изложил в предыдущем абзаце.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Воскресенье, 19 Декабрь, 2010 13:56 
Модератор
Аватара пользователя

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
2Galkov:

Впрочем, понятен Ваш пример - у Вас не глобальный контекст, Вы показали внутренность объекта, так?

Отсюда встречный пример, полный аналог, в качестве делегатов и адаптеров использованы обычные процедуры. Просто мы в КП совсем подзабыли о классическом обероновском стиле работы с объектами.

Пример:

Код:
DEFINITION Buttons;

   TYPE
      Handler = PROCEDURE (obj: ANYPTR);

   PROCEDURE New (IN caption: ARRAY OF CHAR; handler: Handler; obj: ANYPTR): Views.View;

END Buttons.

DEFINITION Players;

   TYPE
      Player = POINTER TO ABSTRACT RECORD
         (p: Player) Play ( ... ), NEW, ABSTRACT;
         (p: Player) Stop ( ... ), NEW, ABSTRACT
      END;

   PROCEDURE New (...): Player;

END Players.

MODULE Desks;

   IMPORT Views, Buttons, Players;

   TYPE
      Desk = POINTER TO RECORD (Views.View)
         playButton, stopButton: Views.View;
         player: Players.Player
      END;

   PROCEDURE PlayHandler (obj: ANYPTR);
   BEGIN
      obj(Desk).player.Play(...)
   END PlayHandler;

   PROCEDURE StopHandler (obj: ANYPTR);
   BEGIN
      obj(Desk).player.Stop(...)
   END Stophandler;

   PROCEDURE New* (...): Views.View;
      VAR d: Desk;
   BEGIN
      NEW(d); d.player := Players.New(...);
      d.playButton := Buttons.New("Play", PlayHandler, d);
      d.stopButton := Buttons.New("Stop", StopHandler, d);
   END New;

END Desks.


Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 179 ]  На страницу Пред.  1, 2, 3, 4, 5, 6, 7, 8, 9  След.

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 8


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
cron
Вся информация, размещаемая участниками на конференции (тексты сообщений, вложения и пр.) © 2005-2024, участники конференции «OberonCore», если специально не оговорено иное.
Администрация не несет ответственности за мнения, стиль и достоверность высказываний участников, равно как и за безопасность материалов, предоставляемых участниками во вложениях.
Без разрешения участников и ссылки на конференцию «OberonCore» любое воспроизведение и/или копирование высказываний полностью и/или по частям запрещено.
Powered by phpBB® Forum Software © phpBB Group
Русская поддержка phpBB