OberonCore

Библиотека  Wiki  Форум  BlackBox  Компоненты  Проекты
Текущее время: Вторник, 19 Март, 2024 08:34

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




Начать новую тему Ответить на тему  [ Сообщений: 179 ]  На страницу 1, 2, 3, 4, 5 ... 9  След.
Автор Сообщение
 Заголовок сообщения: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 16:04 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Выделено из viewtopic.php?f=8&t=2121&start=20
Валерий Лаптев писал(а):
Это все без разницы: для обучения программированию это - вредно!
Валерий, на этот раз я знаю и еще специалистов, не согласных с Вами (кроме себя)
Это те, кто ввели вышеупомянутые слоты/сигналы в QT и делегатов в додиезе... Независимо друг от друга, скорее всего. Да и дяденьку Бормана к дуракам причислять у меня нет пока оснований...


Сергей Губанов писал(а):
Потому что выгоды от него в КП кот наплакал, так как в КП "сообщения рулят"
Пока не убедительно. Давайте сравнивать методом "пальцем покажи"...
Было бы интересно.


Евгений Темиргалеев писал(а):
В КП есть метаинформация. По-моему это оно самое.
Не, не понял :(
Видно это (метасредства) пока не самая моя сильная сторона :)

Давайте конкретизируем задачу. До полного безобразия, скажем.
Вот в винде есть такое сообщение для ListView
MSDN писал(а):
lResult = SendMessage( // returns LRESULT in lResult
    (HWND) hWndControl, // handle to destination control
    (UINT) LVM_SORTITEMS, // message ID
    (WPARAM) wParam, // = (WPARAM) (LPARAM) lParamSort;
    (LPARAM) lParam // = (LPARAM) (PFNLVCOMPARE) pfnCompare; );
Parameters
lParamSort
    Application-defined value that is passed to the comparison function.
pfnCompare
    Pointer to the application-defined comparison function. The comparison function is called during the sort operation each time the relative order of two list items needs to be compared.
Return Value
    Returns TRUE if successful, or FALSE otherwise.
Remarks
    The comparison function has the following form:
    int CALLBACK CompareFunc(LPARAM lParam1, LPARAM lParam2, LPARAM lParamSort);

И что мы подсовываем в сообщение в качестве CallBack-а :?:
Да тот же procedure of object, если не шибко заморачиваться на порядок аргументов в нем

Вот и вопрос: как это реализовать (в смысле, какой мост построить) в ББ/КП, чтобы не дать пользователю применять методы чужого класса(типа) к передаваемому объекту :?:


P.S. Евгений, ну не виноват я в возникновении "диспута" на пустом месте :D


Вернуться к началу
 Профиль  
 
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 16:09 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Galkov писал(а):
Никак пока в толк не возьму, отчего в КП нет такого полезного типа :(
Что-то я его смысла не пойму. Что этот тип делает?

Первое, что приходит в голову - мутация какая-то : ). Вот, например, человек. Состоит из клеток. Почти все клетки как клетки, а эти выпендриваются: делятся как им вздумается.

Это новый тип полиморфизма?


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Galkov писал(а):
P.S. Евгений, ну не виноват я в возникновении "диспута" на пустом месте :D
Никто не против обсуждений. Форум для этого предназначен. Но давайте, пожалуйста, постараемся начинать диспут в соответствующем теме месте.


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Galkov писал(а):
Выделено из viewtopic.php?f=8&t=2121&start=20
Валерий Лаптев писал(а):
Это все без разницы: для обучения программированию это - вредно!
Валерий, на этот раз я знаю и еще специалистов, не согласных с Вами (кроме себя)
Это те, кто ввели вышеупомянутые слоты/сигналы в QT и делегатов в додиезе... Независимо друг от друга, скорее всего. Да и дяденьку Бормана к дуракам причислять у меня нет пока оснований...

Уточняю: для обучения начальным основам ООП скрытый параметр - это ВРЕДНО!
В КП - гораздо лучше: параметр ЯВНЫЙ.


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

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Valery Solovey писал(а):
Первое, что приходит в голову - мутация какая-то : )

Ну вот видите, какая ерунда Вам приходит в голову, основываясь на аксиоматическом подходе :D
А для тех, кто руководствуется "атомно-молекулярной" - приходит совсем другое.
Спрашивается, что можно сделать с адресом метода, и адресом объекта именно этого (что гарантировано во время компиляции) класса :?:
Только одно - вызвать этот метод для этого объекта :!: И ничего другого (если не заниматься хакингом) :!:
Элементарно же, Ватсон !!!!!!!

Зачем? Вообще-то, это интегрированный патерн Command. Откроем букварь, и посмотрим, что делает этот патерн...
Поскольку, я знаю, что Вам известна реализация полиморфизма, то могу рассчитывать, что мои слова не будут непоняты.

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

Ну как, оказывает пользу знание "атомно-молекулярной теории", или нет :?:
Обратите внимание, я ведь совершенно не спорю, что классикой можно пользоваться, но так и никогда не узнать правды.
И быть счастливым :)



Валерий Лаптев писал(а):
Уточняю: для обучения начальным основам ООП скрытый параметр - это ВРЕДНО!

Тоды ОЙ :D
Можно даже сказать - присоединяюсь....


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

Зарегистрирован: Четверг, 17 Ноябрь, 2005 11:51
Сообщения: 2935
Откуда: г. Ярославль
Есть сильное подозрение, что паттерн Command реализован в BlackBox как Stores.Operation...


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Иван Кузьмицкий писал(а):
Есть сильное подозрение, что паттерн Command реализован в BlackBox как Stores.Operation...
У меня более банальное подозрение - это коммандер :) (т.е. StdInterperter, т.е. Meta). Частично его провоцирует то, что тут упоминались сигналы/слоты Qt...

Galkov писал(а):
Спрашивается, что можно сделать с адресом метода, и адресом объекта именно этого (что гарантировано во время компиляции) класса :?:
Только одно - вызвать этот метод для этого объекта :!: И ничего другого (если не заниматься хакингом) :!:
В метаинформацию ББ1.6 влючены описания параметров. Это, если не ошибаюсь, позволяет вызывать любой метод любого объекта. В 1.5 на тип процедуры было ограничение, - один параметр ANYREC, кажется...

Особых абстракций для этого не нужно.


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

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

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

В принципе, никаких препятствий к реализации такой схемы библиотечно нет.

Я делал сигналы системного назначения, где 128-бит-запись хранила адрес модуля (Kernel.Module), смещение процедуры в нём, и дальше - байты контекста (которые, в свою очередь, могут быть номерами более крупных объектов в каких-то глобальных массивах...). Перед активацией сигнала выполняется проверка, что модуль ещё не выгружен.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 26 Ноябрь, 2009 21:34 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
А я из объяснений - надеюсь - понял, что описываемый механизм можно выразить так:
CmdExec(...) = obj.Exec(...)

Где obj - объект,
Exec - его метод,
CmdExec - переменная указанного типа,
= - эквивалентность.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Пятница, 27 Ноябрь, 2009 13:47 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Дык нет у меня сомнений, что все это можно реализовать.
У меня есть соображение (возможно и ошибочные!!!), что эффективно это можно реализовать только врезавшись в Язык, но не конструируя сие из уже заданного...

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

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

И вот примерно так я бы это делал на Дельфи (в смысле, имея в виду, что мои объекты имеют поля Event типа procedure of object, ну и используют их, естественно)
Код:
// Запускаем фабрики, для установки элементов на плату
  Тумблер1  := NewТумблер('Подумать');
  Тумблер2  := NewТумблер('Решить');
  Тумблер3  := NewТумблер('Хорошо решить');
  Тумблер4  := NewТумблер('Хорошо подумать');
  Тумблер5  := NewТумблер('Подумать над решением');
  Решатель1 := NewРешатель();
  Решатель2 := NewРешатель();
  Думатель1 := NewДуматель();
  Думатель2 := NewДуматель();

// Соединяем элементы между собой
  Тумблер1.Event := Думатель1.БыстроПодумать; // это Провод1
  Тумблер2.Event := Решатель1.ПростоРешить;   // это Провод2
  Тумблер3.Event := Решатель2.РешитьПодумавши;// это Провод3
  Решатель2.Event:= Думатель2.ХорошоПодумать; // это Провод4
  Тумблер4.Event := Думатель1.ХорошоПодумать; // это Провод5
  Тумблер5.Event := Думатель2.БыстроПодумать; // это Провод6
  Думатель2.Event:= Решатель1.ПростоРешить;   // это Провод7

А как это сделать на языках, не имеющего такого славного типа, спрашивается :?:
Мое сегодняшнее понимание таково, поля Event теперь должны иметь тип указателя на абстрактный класс Command.
А я, лично, в этом же модуле, должен определить 7 (семь!!!) расширений этого класса, и, соответственно нарисовать 7 процедур примерно в таком стиле:
Код:
TYPE Command3 = EXTENSIBLE RECORD(Command)END;
PROCEDURE (VAR self:Command3)Execute();
BEGIN
  Решатель2.РешитьПодумавши();
END Execute;

И дополнить секцию созидания 7 (семь!!!) раз в таком стиле: Провод3 := New(Command3);

Может я чего не понимаю....
Откройте мне глаза, пожалуйста, чтобы можно было адекватно провести сравнение эффективности двух механизмов.
Ибо на уровне моего сегодняшнего понимания, сравнивать сие как по эффективности, так и по пользовательскому интерфейсу - как-то и неловко даже... :(


Последний раз редактировалось Galkov Пятница, 27 Ноябрь, 2009 14:12, всего редактировалось 1 раз.

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

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

Если он возникает из САПРовых задач, где эти объекты и их соединения являются не архитектурой программы, а обрабатываемыми программой.. то логично завести какой-нибудь базовый тип Element и т.п. и уже от него плясать.

Если же какая-то конкретная задача, то много вариантов может быть.

У того же думателя естественно завести одну процедуру Думать и параметризовать её - как именно думать. В общем случае можно параметризовать RECORD-сообщением.
Ведь думаний может быть много - не изменять же определение типа при каждом развитии программы?


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Пятница, 27 Ноябрь, 2009 15:22 
Аватара пользователя

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Galkov писал(а):
А я, лично, в этом же модуле, должен определить 7 (семь!!!) расширений этого класса, и, соответственно нарисовать 7 процедур примерно в таком стиле:
Код:
TYPE Command3 = EXTENSIBLE RECORD(Command)END;
PROCEDURE (VAR self:Command3)Execute();
BEGIN
  Решатель2.РешитьПодумавши();
END Execute;
Наоборот, не в команде написать метод Execute, а в Решатель2 надо реализовать обработку соответствующего сообщения. У сообщений методов нет.

1) Надо описать типы сообщений.
2) Соединить тех кто сообщения отправляет с теми кто их обрабатывает.

Основа для них:
Код:
DEFINITION Generic;

  TYPE
    Message = ABSTRACT RECORD END;

    Recipient = POINTER TO ABSTRACT RECORD
      (this: Recipient) HandleMessage (VAR message: Message), NEW, ABSTRACT;
    END;

END Generic.

Затем:
Код:
DEFINITION Думатели;
 
  IMPORT Generic;

  TYPE
    БыстроПодумать = RECORD (Generic.Message) END;
    ПодуматьВдумчиво = RECORD (Generic.Message) END;
    КакСледуетПодумать = RECORD (Generic.Message) END;

    Думатель = POINTER TO ABSTRACT RECORD (Generic.Recipient) END;

END Думатели.
Код:
DEFINITION Решатели;
 
  IMPORT Generic;

  TYPE
    БыстроРешить = RECORD (Generic.Message) END;
    ВдумчивоРешить = RECORD (Generic.Message) END;
    КакСледуетРешить = RECORD (Generic.Message) END;

    Решатель = POINTER TO ABSTRACT RECORD (Generic.Recipient) END;

END Решатели.


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

Зарегистрирован: Суббота, 07 Март, 2009 15:39
Сообщения: 3261
Откуда: Астрахань
Классные просто названия типов!!!!!
Очень мне нравятся!


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Суббота, 28 Ноябрь, 2009 03:14 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Хм-м-м...............
Сергей Губанов писал(а):
Наоборот, не в команде написать метод Execute, а в Решатель2 надо реализовать обработку соответствующего сообщения. У сообщений методов нет
Правильно ли я понял :?:
1) Все "приемники" должны быть наследником Recipient-а, и персонально конкретизировать HandleMessage
2) Все "передатчики" содержат поле, скажем Event, типа Recipient. Куда и присваиваются экземпляры Думателей и Решателей
3) При "передаче" делается Event.HandleMessage(Msg), где Msg какая-нибудь локальная переменная соответствующего типа. И которые могут вообще ничего не содержать, короме невидимого для программиста указателя на дескиптор типа, который и несет главную смысловую нагрузку.
4) Обработчики HandleMessage первым делом делают знаменитый WITH по типам, и в каждой егойной ветке, предположим, вызывают нужный метод объекта.
5) И такая фишка является типовой в каркасах ББ. Так ли :?:


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

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

Касательно "обработчики вызывают методы" - там уже не методы, а просто скрытые процедуры модуля делаются обычно. В большинстве случаев (кроме "прикладно оправданных") неэкспортированные процедуры не делаются связными, незачем.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 03 Декабрь, 2009 00:14 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
А как было хорошо и понятно было в Дельфи :D

2 Сергей Губанов - спасибо за разъяснения механизма сообщений. Честно говоря, не сразу въехал... Видимо от того, что мой мозг не очень привык к использованию RTTI (грубо говоря, вообще никогда не использовал)

Ну перейдем к сравнению... Конечно же, я немного лукавил про сравнение: мне сразу было известно, что эффективнее, чем это сделано с использованием procedure of object - сделать нельзя. С уровнем доверия три девятки.
Ну значит так, на момент "использования" происходит примерно следующее:
    1. procedure of object в Дельфи
    1.1. Накиданы аргументы в стек, в соответствии с сигнатурой типа
    1.2. Кидаем в стек параметр self (он же this, смещение +4 в поле Event)
    1.3. Делаем косвенный вызов по адресу, лежащему по смещению +0 в поле Event
    1.4. Исполняем нужный нам код

    2. Сообщенние в КП
    2.1. Накиданы аргументы в поля сообщения. Будем считать их полностью соответствующими сигнатуре типа по п.1.1. И лежат эти поля тоже в стеке (локальная переменная типа Message)
    2.2. Кидаем в стек адрес нашей переменной типа Message (VAR-переменная в HandleMessage)
    2.3. Добываем из поля Event адрес объекта-получателя
    2.4. Кидаем его в стек, как параметр self (он же this) для HandleMessage
    2.5. Добываем из vmt этого объекта адрес метода HandleMessage, и делаем вызов этого метода. Одна операция косвенного вызова, видимо.
    2.6. В методе HandleMessage первым делом добываем адрес дескриптора типа для принятого сообщения. Как точно - не знаю. Не думаю, что сложнее чем какое-то количество косвенных обращений в память. Подозреваю, что одно
    2.7. Осуществляем WITH-селектирование по типу. Опять же, точного механизма не знаю. Но подозреваю, что для каждой ветки происходит вызов некой системной ф-ии, которая просматривает список предков полученного типа, и сравнивает его с нужным для данной ветки. В смысле, посложнее будет, чем банальный CASE
    2.8. Исполняем нужный нам код. В соответствии с рекомендацией Ильи, не напрягаться с лишними вызовами методов объекта. Впрочем, я и сам всегда считал логически правильным, возложить ответственность за inline однократно используемой процедуры - на компилятор

И что у нас получается? В смысле, на много ли хуже система сообщений в КП, чем практически идеальная по п.1...
На несколько (скажем - парочку) обращений в память, и плюс на, не очень понятную по эффективности, систему WITH-селектирования
Как говорится, не так уж и плохо - нет промежуточных функциональных вызовов, как в тупом применение патерна Command, что я показывал... Хотя, там не было селектирования...
Но что главное-то хотел я сказать: обойти по эффективности применение procedure of object - практически не реально

И представить, в связи с этим, на Ваше внимание некое "философское" обобщение:
Процедурный тип, при появлении ООП (в смысле - методов класса/типа) требует некой модификации. Ну или адаптации... И, думается - не вместо, а в дополнение.
И примеров таких "модификаций" я вижу два: как в C++ (там этот тип называется методы класса), и как в Дельфи (procedure of object). Ну а остальное Вы слышали, наверное - не сдержался я, и в других ветках проболтаться успел

И вот, в связи с вышесказанным, мне хотелось бы повторить для КП-сообщества стартовую фразу: "Никак пока в толк не возьму, отчего в КП нет такого полезного типа"
Думал-думал - ну ничему не противоречит вроде... Появляется и "защита" - работает как все указательные типы...

Что скажите коллеги :?:
Мне так кажется, что: быстр, вынослив, и кормить не надо :)


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

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

По поводу сопоставления типа. Простой IS выполняется так: известен level сопоставляемого типа. В дескрипторе любого типа прямая таблица всех базовых типов. Обращаемся obj->type->base[level] и сравниваем с проверяемым типом.

WITH, видимо, как IF x IS... ELSIF x IS...
Табличной оптимизации тут не видится; да и вряд ли она что-то даст.


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 03 Декабрь, 2009 01:26 

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Galkov писал(а):
И что у нас получается? В смысле, на много ли хуже система сообщений в КП, чем практически идеальная по п.1...
Да практически тоже самое. Вещи, на которые Вы указали в ББ как на потребляемые лишнее время, есть и в Делфи. И для реализации аналогичных механизмов в программе они обязаны использоваться. И используются. Нету WITH после вызова? Значит есть перед ним.


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 18:55
Сообщения: 2272
Откуда: Россия, Нижний Новгород
Galkov писал(а):
Но что главное-то хотел я сказать: обойти по эффективности применение procedure of object - практически не реально
Ну изготовьте этот тип сами если он Вам так нравится:
Код:
TYPE
  MyProcedure* = PROCEDURE (this: ANYPTR; ... аргументы...);

  MyProcedureOfObject* = RECORD
    object*: ANYPTR;
    procedure*: MyProcedure;
  END;

  PROCEDURE (VAR this: MyProcedureOfObject) Init* (object: ANYPTR; procedure: MyProcedure), NEW;
  BEGIN ASSERT(object # NIL, 20); ASSERT(procedure # NIL, 21);
    this.object := object; this.procedure := procedure
  END Init;

  PROCEDURE (IN this: MyProcedureOfObject) Invoke* (... аргументы...), NEW;
  BEGIN ASSERT(this.object # NIL, 100); ASSERT(this.procedure # NIL, 101);
    this.procedure(this.object, ... аргументы...)
  END Invoke;


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Аналог procedure of object в КП
СообщениеДобавлено: Четверг, 03 Декабрь, 2009 14:46 

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

Давайте на секунду забудем, что есть какой-то там ООП, и все с ним связанное.
Есть у нас возможности делать вариантность/переменность исполнения неких команд модуля???
Да конечно же - вот же он, процедурный тип!!! Вплоть до смены поведения на лету
Если мы договоримся о том, что нам совершенно понятны схемы применения, которые будут покрыты этим типом, то дальше-то - все очень просто.
Ну вот, пришла беда, откудова не ждали - ООП называется. И сторонние разработчики стали нам предоставлять не имена процедур, а методы объектов. И не очень уточняют за их виртуальность - типа нам это должно быть не важно. Что, вообще-то, сильно похоже на правду.
Спрашивается, какое самое естественное (простое, эффективное, и т.п.) расширение этого процедурного типа, чтобы использовать те "схемы", про которые мы договорились, что нам они давно и хорошо известны.
Ответ: procedure of object. Который не более, чем добавление еще одного адреса (this) в хранимые данные, потому-что при применении (функциональном вызове) без него не обойтись.
Что, спрашивается, может быть проще в исполнении???


Сергей Губанов писал(а):
Ну изготовьте этот тип сами если он Вам так нравится:
Вот именно так мне и не нравится.
Потому-что это технология Zero Errors
1) На самом деле я должен изготовлять не очень предсказуемое число типов, меняя ANYPTR на мои конкретные типы. Не знаю, но это не кажется рациональным для языков с RTTI - создаем некому не нужный мусор в виде дескрипторов типа. Оно нам надо?
2) В C++ так и делают с помощью шаблонов. А сделавши, говорят: "ну и фигня же получилась", и начинают делать QT - прошу принять это как экспериментальный факт.
3) Типы в полях структуры (которые обозначены как ANYPTR) должны быть тождественны - быть наследником недопустимо, А Язык это легко пропустит для метода Init
4) Может я не понял, но не увидел того самого "связывания", которое должно происходить в Init
5) Про Invoke - меня и в дельфях достали продпрограмки, только и делающие, что вызывающие другую подпрограмку. Которая опять такая же... Хотя, возможно(!!!), я не все еще освоил, и опция inline в КП есть...

Но главное-то в том, что не получается такой тип некими стандартными средствами композиции. Несмотря на всю его исполнительную простоту.
Ну не получается, хучь в ухо мочись!!!
Вот напишем тип для некой переменной procedure(R:real) of object - и эта переменная совместима как для метода "умножить" какого-то вычислителя, так и для метода "передвинуть" какого-нибудь робота.
Лишь бы сигнатуры совпадали, естественно... А тип - да по барабану, если это метод именно этого типа (а не его предка)
Тип структуры с двумя полями разных типом - это структурное прозведение
И это не от того, что мы такие умные, и так хитро придумали, а потому что "отсылателю сообщения" на самом деле по-барабану кто будет исполнять сигналы/команды.
Нооборот все: если правда жизни говорит нам, что "по-барабану", то нам именно так и надо придумывать.
((стоп себе думаю... кажется сейчас я сформулировал идеологическое различие между физиками и математиками 8) ))


Valery Solovey писал(а):
Нету WITH после вызова? Значит есть перед ним
Неправда Ваша. Вовсе не значит. Если мы осуществляем селектирование, значит сначала кто-то это объединил в одно целое. Только это. Но совершенно не значит, что без этого объединения не обойтись.
Обойтись. И существует много случаев, когда это "обойтись" выглядит значительно проще и естественней.


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

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


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

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


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

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