OberonCore
https://forum.oberoncore.ru/

Аналог procedure of object в КП
https://forum.oberoncore.ru/viewtopic.php?f=29&t=2125
Страница 6 из 9

Автор:  Info21 [ Воскресенье, 19 Декабрь, 2010 13:57 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

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

Автор:  Илья Ермаков [ Воскресенье, 19 Декабрь, 2010 14:04 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Но это был пример "для разминки", просто аналог начальному игрушечному примеру. На самом деле, при соединении объектов нужно пересылать сигналы разных типов, заранее неизвестных. Поэтому немного модифицируем пример. Процедура-делегат должна получать свой объект, объект-источник и расширяемое VAR-сообщение.

Вот так (обратите внимание, теперь в Desks осталась только одна процедура обработки):

Код:
DEFINITION Buttons;

   TYPE
      Handler = PROCEDURE (obj, sourceObj: ANYPTR; VAR msg: ANYREC);
      ClickMsg = RECORD ... END;

   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 Handler (d, sourceObj: ANYPTR; VAR msg: ANYREC);
   BEGIN
      WITH d: Desk DO
         IF msg IS Buttons.ClickMsg THEN
            IF sourceObj = d.playButton THEN
               d.player.Play(...)
            ELSIF sourceObj = d.stopButton THEN
               d.player.Stop(...)
            END
         END
      END
   END Handler;

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

END Desks.

Автор:  Александр Ильин [ Воскресенье, 19 Декабрь, 2010 15:39 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Илья Ермаков писал(а):
d.playButton := Buttons.New("Play", PlayHandler, d);
d.playButton := Buttons.New("Play", StopHandler, d);
Илья, вы закончили работать над сообщением? Или ещё рано вчитываться?

Автор:  Илья Ермаков [ Воскресенье, 19 Декабрь, 2010 18:39 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Спасибо, поправил!

Автор:  Илья Ермаков [ Воскресенье, 19 Декабрь, 2010 21:14 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

По примерам этого обсуждения составил статью в Вики:
http://oberoncore.ru/wiki/blackbox/ex/delegates

Доступна со страницы примеров - http://oberoncore.ru/wiki/blackbox/ex/start

Автор:  Comdiv [ Воскресенье, 19 Декабрь, 2010 23:00 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

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

Автор:  Илья Ермаков [ Воскресенье, 19 Декабрь, 2010 23:18 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Это можно рассматривать как предупреждение о том, что собирались как-то этот кусок языка ревизионировать.

Однако реальность такова, что:
А. В текущей реализации ББ:
- без процедурного типа невозможно вызвать процедуру через метапрограммирование (т.к. ссылку же надо в какую-то переменную принять). А на командах и символическом связывании с процедурами построены ключевые средства среды.
- без процедурного типа невозможна интеграция с внешним миром.
Ввиду сказанного можно быть уверенным, что максимум, что задумывали авторы КП, это убрать процедурный тип в SYSTEM.
Б. В "общем масштабе":
- существует и развивается ветка классического Оберона в виде Оберона-07. Там всё ООП основано на процедурах. Лишать КП возможности применения этого стиля проектирования нехорошо.
- при применении КП для системных задач процедурный тип начинает нести приличную нагрузку. При этом я имею в виду высокоуровневые системные задачи (решаемые без SYSTEM).

Автор:  Galkov [ Понедельник, 20 Декабрь, 2010 12:36 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Илья Ермаков писал(а):
Для этого понадобилось бы вводить совместимость методов и процедур вида (object, ...), а потом позволять устанавливать делегат не только присваиванием .. := объект.Метод; но и чем-то типа присваивания пары .. := (объект, обычнаяПроцедура). Такого я не припоминаю ни у Борланда, ни где-то ещё (хотя технически это реализуемо, разумеется).

Илья Ермаков писал(а):
Только интерфейсы в таком случае получаются одноэземплярные, т.е. существует глобально в приложении контекст ровно на один экземпляр интерфейса. В большинстве случаев это даже хорошо. Но для обсуждаемой нами задачи (связывать динамически объекты) это слишком частный случай.
Илья Евгеньевич, давайте еще раз откроем Америку...
Pieter Muller писал(а):
Procedure types have been extended so that procedure variables can also store references to methods, not just to normal procedures. A procedure variable now also stores a reference to an object instance, which is NIL in the case of normal procedure variables. The type of a method is identical to that of a procedure with the same signature, making it compatible with procedure variables of the same procedure type.
Да и свои соображения про техническую реализуемость - писал вроде. Как на самом деле - не знаю, не дошел еще. Не исключено, что коллега BohdanT знает детали... Мне показалось - любит он подсматривать подробности (а главное - умеет).

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

Автор:  Илья Ермаков [ Понедельник, 20 Декабрь, 2010 13:01 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Всё, читайте примеры и статью в Вики, решение проблемы показано.

На этом тему делегатов считаю исчерпанной, потому что паттерн их реализации на основе обычных процедурных переменных найден.
Спасибо Вам за стимуляцию мышления, "попинали" с пользой.

Автор:  Galkov [ Понедельник, 20 Декабрь, 2010 13:48 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Ну давайте пошерстим вики...

Цитата:
На их основе участник форума Галков привёл пример....
Мне думается лучше конкретно и точно указать, что не я Автор примера-то. Двусмысленность может получиться - не все же по ссылке в топик сходят. Это код из ActiveReport. Да и настороженно я отношусь к упоминанию фамилии в суе. :)
НО :arrow: это не более чем мнение, а решение, безусловно, принадлежит Автору статьи.

Цитата:
Достаточно распространённый прием в Компонентном Паскале
Мне думается, что можно бы и указать, что это реализация одного из паттернов от банды 4-х (Command кажется - не помню точно). И рассказать, что они-то не обременены были расположением объектов именно в хипе...
И что применение их паттернов в языках с GC имеет некоторые особенности.
Это я к тому, что если вики читает свежий человек - правдивые подробности не помешают

Цитата:
При таком взгляде делегат можно представить как пару из процедурной переменной и указателя на объект, типа:: RECORD handler: PROCEDURE(obj: ANYPTR; ..другие параметры..); obj: ANYPTR) END. Объект, владеющий такой парой, может инициировать для другого объекта операцию.
Мне думается, что в этом разделе следует поподробнее разжевать, почему используется тип ANYPTR, а не, скажем, Desk. Втолковать новичку, на каком уровне абстракции ему следует находиться, проектируя таковые схемы.
Мне думается, что стиль "профессионалы объясняют для профессионалов" - не очень правильный для вики... У меня, к примеру, есть свое личное отношение к таковым "профессионалам" :D

Цитата:
Вышеприведённый пример слишком «игрушечный». На самом деле, при соединении объектов нужно пересылать сигналы разных типов, заранее неизвестных.

Модифицируем пример, чтобы показать более общий подход.
Абсолютно неубедительно.
Вы же русским языком написали handler: PROCEDURE(obj: ANYPTR; ..другие параметры..) (пардон - английским).
Кто определил сигнатуру хэндлера ??? разработчик элемента (в нашем случае - батона). Точка.
Разработчик элемента определил железно сигнатуру входных разъемов - тут почему-то никто дискомфорта не испытал.
Ровно также, железно, он определяет сигнатуру своих выходных разъемов.
А разработчик системы создает свою промежуточную логику, принимая цоколевки всех разъемов, как незыблемую данность.
Где проблемы ??? Где игрушечность, спрашивается ???

Но внутренним чувством я понимаю, что аргументы для перехода от "нервных связей" к "химии" (которая очень увлекательно будет выглядеть для системы из пары сотен объектов... а главное - понятно) - ЕСТЬ.
Ну сохранила Природа в живых организмах Химию. Несмотря на появление нервных связей. Как в виде безусловных рефлексов, так и в виде более продвинутом - условных. Не доказательство, но очень серьезный повод задуматься.

Так давайте честно искать эти аргументы, а не декларировать записи на скрижалях.
Нельзя писать вики так, чтобы зашедший туда человек мог сказать: "Чего Вы мне фуфло гоните!!!"

Автор:  Galkov [ Понедельник, 20 Декабрь, 2010 13:55 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Илья Ермаков писал(а):
Всё, читайте примеры и статью в Вики, решение проблемы показано
Ну Вы даете, блин.

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

Большое спасибо за уважение. DIXI

Автор:  Geniepro [ Понедельник, 20 Декабрь, 2010 14:03 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Делегаты, делегаты...
Я в своих программах на С# использую какие-то делегатные типы без особого понимания что и как там делается, просто потому, что так принято для безопасного влияния на ГУИ из многопоточных программ.

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

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

Автор:  Илья Ермаков [ Понедельник, 20 Декабрь, 2010 14:04 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Цитата:
Мне думается, что в этом разделе следует поподробнее разжевать, почему используется тип ANYPTR, а не, скажем, Desk. Втолковать новичку, на каком уровне абстракции ему следует находиться, проектируя таковые схемы.


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

Цитата:
Мне думается, что стиль "профессионалы объясняют для профессионалов" - не очень правильный для вики... У меня, к примеру, есть свое личное отношение к таковым "профессионалам"


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

Цитата:
Абсолютно неубедительно.
Вы же русским языком написали handler: PROCEDURE(obj: ANYPTR; ..другие параметры..) (пардон - английским).


Да, но это многоточие было здесь на форуме. А в Вики во втором примере для простоты оставлен только obj. Потому потом и говорится об "игрушечности". Можно, конечно, сказать, что стоит иметь промежуточный вариант, где ещё нет общего VAR msg, а просто какие-то конкретные параметры. Однако я в своей практике, если сначала было без параметров, а потом вдруг пришлось их добавлять, сразу уже перехожу к общему VAR msg - потому что, скорее всего, понадобится и ещё раз расширяться. А рушить совместимость и провоцировать перекомпиляцию других модулей не всегда возможно. Т.е. либо, если уверены, что ну никогда ничего не поменяется, можем объявить конкретные параметры (или без них), либо уже стоит сразу "точку неограниченного расширения" заложить.

Автор:  Илья Ермаков [ Понедельник, 20 Декабрь, 2010 14:06 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Galkov писал(а):
Сколько же можно относиться к собеседнику как к лоху, который понятия не имеет как это можно реализовать. Это не уважительно, в конце концов.
Не было никогда такой проблемы (решение которой показано).


Хорошо, можете считать лохом меня, потому что я НЕ ВИЖУ проблемы. В упор. До показанного решения я видел некоторые неудобства с этими промежуточными объектными типами и лишними динамическими объектами.

С найденным паттерном лично я не могу вообразить, для чего мне могут потребоваться делегаты.

Автор:  Galkov [ Вторник, 21 Декабрь, 2010 08:14 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Илья Ермаков писал(а):
Хорошо, можете считать лохом меня, потому что я НЕ ВИЖУ проблемы. В упор
Ваше великодушие избыточно.
Достаточно просто предположить, что лохами не являлись разработчики Борланда, Active Oberon, QT.
Они увидели проблему.
Это, правда, может потребовать времени, которого у Вас нет.
Ну что же, не знайте например, что проверка типа obj(Desk).player.Play(...) в runtime - не эквивалентна аналогичной при раннем связывании ... := obj.Method
Продолжайте думать, что никто лучше Вас не знает, что новичку понятно, а что - нет.
Да и много чего еще... Писать - так Вы по диагонали прочитаете, времени-то нету.

И живите счастливо. Меньше знаешь - крепче спишь

Автор:  Илья Ермаков [ Вторник, 21 Декабрь, 2010 08:55 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Galkov писал(а):
obj(Desk).player.Play(...)[/color] в runtime - не эквивалентна аналогичной при раннем связывании ... := obj.Method
Продолжайте думать, что никто лучше Вас не знает, что новичку понятно, а что - нет.


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

Таким образом, obj.Method будет тоже связываться в рантайме.
Не говоря про то, что ВО ВСЕХ ИНТЕРЕСНЫХ СЛУЧАЯХ у Вас будет между источником сигнала и его получателем какое-то посредничество. Та самая процедура Init000 из Вашего примера или Handle из моего. Так что заморачиваться о проблемах эффективности связывания - это неумение абстрагироваться от частного "мусора" задач.

===

Цитата:
Достаточно просто предположить, что лохами не являлись разработчики Борланда, Active Oberon, QT.
Они увидели проблему.

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

Я в ЛС приводил Вам пример, но Вы обратили внимание не на ту цифру в нём. А там был факт, что в одном тестовом интерпретаторе выражений я вводил косвенность с выносом всех числовых значений на отдельные объекты, доступные через указатели. И не наблюдал замедления вообще. Так работает конвейер-суперскаляр с кэшем. А Вы всё ещё такты пытаетесь считать.

А знаете, сколько косвенностей в сетевых протоколах с коммутацией пакетов. Может быть, придумаем специальный протокол для на 10% более быстрой связи межу двумя этажами? Заделаем коммутацию каналов? Жалко же, 10% пропадает.

===

А "Борланды" понятия не имеют о компонентном программировании (вспомнить только жуткие многоуровневые иерархии наследования в VCL). (Не говоря про то, что JIT они ходили заказывать в Oberon Microsystems). В AO засунули просто "ещё одно удобное средство".

Автор:  Info21 [ Вторник, 21 Декабрь, 2010 12:22 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Илья Ермаков писал(а):
"Борланды" понятия не имеют о компонентном программировании (вспомнить только жуткие многоуровневые иерархии наследования в VCL).
Не только Борланды. ЦЕРН со своим физическим фреймвоком тоже отметился в этом пункте по полной.

Илья Ермаков писал(а):
Не говоря про то, что JIT они ходили заказывать в Oberon Microsystems.
Да, почаще об этом надо напоминать :)

Автор:  Galkov [ Среда, 22 Декабрь, 2010 08:30 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Илья Ермаков писал(а):
Таким образом, obj.Method будет тоже связываться в рантайме
Не рассказывайте мне сказки. Просто посмотрите в коды. Не обероновские, естественно. Ну, и конечно, если у Вас найдется время.
Но Вы не поняли главное.
В коде obj(Desk).player.Play(...) может ошибочно стоять наследник Desk-а, у которого такового метода вообще может не быть, или быть переопределенным.
Защита пробита.

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

Вещь элементарная. Просто надо захотеть ее увидеть, для чего, в свою очередь, надо обязательо предположить, что не все, излагаемое коллегами является бредом сивой кобылы.
Если Вам это сделать затруднительно, ну или там проблемы со временем, то я, как уже отмечал выше - НЕ НАСТАИВАЮ.
Все понятно и объяснимо.
В том числе и то, что высокие принципы, к которым идет постоянная апелляция на форуме - не более чем легенда прикрытия.
Очень поучительный топик получился, после демонстрации-то конкретных кодов.

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

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

Автор:  Info21 [ Среда, 22 Декабрь, 2010 09:27 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Galkov писал(а):
Но Вы не поняли главное.
Сначала нужно хорошо объяснить.

Я вот, к примеру, тупой и так и не понял, об чем речь. А продираться сквозь слова и выяснять за Вас возможности нет.

Начните с прояснения (архитектурной) проблемы и найдите для нее короткую формулировку, даже если она будет требовать пояснений.

Автор:  Galkov [ Среда, 22 Декабрь, 2010 10:22 ]
Заголовок сообщения:  Re: Аналог procedure of object в КП

Galkov писал(а):
В коде obj(Desk).player.Play(...) может ошибочно стоять наследник Desk-а, у которого такового метода вообще может не быть, или быть переопределенным.
Защита пробита.
Хотя ВОЗМОЖНО я и не прав... Их сов - с утра башка хуже работает.
Впрочем, не очень интересно уже.
Нафига мне проблемы, когда есть варианты надежнее и безопаснее в пользовательском интерфейсе. Без введения новых сущностей и вдвое короче.
btw: в этом и была как бы проблема, которую Вы, Илья, как бы решили, в связи с чем в упор ее видеть не хотите. Еще раз: не настаиваю.

Илья Ермаков писал(а):
Таким образом, obj.Method будет тоже связываться в рантайме
А, понял кажется (см. выше сноску про утро). Может в run-time, (а может и нет - от виртуальноси зависит) но это раннее связывание, а не при каждом вызове.

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