OberonCore https://forum.oberoncore.ru/ |
|
Аналог procedure of object в КП https://forum.oberoncore.ru/viewtopic.php?f=29&t=2125 |
Страница 3 из 9 |
Автор: | Galkov [ Среда, 09 Декабрь, 2009 03:57 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Как бы мне следует принести извинения, что не так оперативно отвечаю....... Но ответить хочется, причем - сильно подумавши. А это требует времени, которое получается "отложенным". Ну дык я собрался |
Автор: | Galkov [ Среда, 09 Декабрь, 2009 03:57 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Valery Solovey писал(а): Да ну? Хорошо. Значит, "селектировать" не надо. Ладно. Тогда скажите мне, как эти думатели будут вызываться? Валерий, я совершено не понял Вашего вопроса: что значит "как" 1. Их было три только для понтов, а на самом деле вызываться будет только первый (остальные будут для балласта). 2. Вызываться они будут в том порядке, в котором они были представлены. 3. Вызываться будут в обратном порядке. 4. Какой-то другой порядок вызова. Если "как", означает: откуда берется сигнал на тумблере - то это отдельная история связанная с устройством винды, визуальных контроллов, и т.п.. Это можно все разъяснить до последнего винтика, хотя и долго... Неясно зачем. Если - после, так я специально для этого п.1. и расписывал. Отличие от вызова процедурного типа - только в одной команде проца, установке дополнительного аргумента this (п.1.2). Возможно я написал и не очень понятно, но непойму в чем неясность-то. И после этого, на пп.2-4 - даже и слов как-то не нахожу, в полном недоумении... Про "понты" замечу - жизнь гораздо разнообразней любых фантазий. Десятками эдаких объектов быть может - и все не для понтов. Зря, однако, я не откомментировался на замечание Ильи про чрезмерную абстрактность примера (собственно, он сделал намек, что ему и так понятно, откуда ноги растут). Но я сделаю это ниже. И даже припомню свою, абсолютно конкретную, и давно сделанную - программульку. Если уж абстрактные примеры вызывают недоверие, мне совершенно непонятное. Valery Solovey писал(а): проблема не в том, что необходимо делать выбор, а в том, когда его производить Проблемы, вообще-то, никакой нет. Есть замечание, что почесать левое ухо можно не только правой ногой (что не представляет, предположим, никакой проблемы), а можно еще - эффективнее в реализации (левой рукой), и понятнее для разработчика. Например, в тот момент, когда я (в смысле, разработчик) пишу строку кода (в патерне системы сообщений в КП): Тумблер3.Event := Решатель2, мне совершенно точно известно, что на самом деле мне надо попасть в метод РешитьПодумавши этого объекта. Просто я этого сказать не могу, нету таких слов в язЫке. Точнее, есть таки - процедурный тип, но он не заточен под ООП, в него не запихаешь метод. Вот я и делаю два действия при проектировании (плюс к вышеуказанной строке - вариантный код в селекторе WITH), и некоторые действия в run time. Хоть не самые страшные, но совершенно без объективных причин. Ибо, чье-то мнение про "финтифлюшки" - не более, чем "условные рефлексы", и субъективно по определению. Valery Solovey писал(а): Топик о том, что кому-то не хватает детальки, без которой обычно можно обойтись Он станет таким как я сказал, ровно в тот момент, когда Вы перестание комплексовать по поводу того, что кто-то обижает Обероны.Не каждая "деталька" является противоречащей Концепции. Возможно, Вы просто не умеете ее готовить. И не все предлагающие, настолько не понимают Концепцию. Вот Илья как-то намекал на отличие КП от "классического" Оберона. Так вот, отличия, привнесенные КП - это тоже такие "детальки", без которых можно прекрасно обойтись. Возможно, я не все правильно понимаю - поправьте меня. Ну подумаешь, пользователь подставит объекту не родной метод (там это процедура). Можно ведь первой строкой и ASSERT влепить, как совершенно справедливо заметил Сергей (или как показал Александр Ильин в этом посте) А мне представляется, что привнесенный комплект "деталек" позволяет разработчику более ясно доносить свои мысли до ИИ, известного более, как компилятор. Причем, это "более ясно" относится к патерну проектирования, известному в народе как ООП. И сопровождется это "более ясно" - большей эффективностью кодов, и большей надежностью проектирования (меньше строков кода - меньше ошибок) Например, гарантирует, что к объекту будут применены только его методы - в том самом ASSERT уже нет и необходимости. И ведь что занимательно, в дельфячей строке Тумблер3.Event := Решатель2.РешитьПодумавши - тоже гарантирована стыковка метода и объекта (более того, именно в этот момент происходит связывание, а не в момент использования) Т.е., деталька procedure of object - абсолютно в стиле тех деталек, которые привнесены КП в классический Оберон. Просто про нее позабыли, и оставили исходный процедурный тип (где-то слышал, что это один из трех китов классического Оберона) без ООП-прикрытия. Незаслуженно, причем |
Автор: | Galkov [ Среда, 09 Декабрь, 2009 03:59 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Евгений Темиргалеев писал(а): В каких задачах эта эффективность даст такие плюсы, чтобы нужно было включать в язык? Это учитывая что ББ-й механизм с сообщениями более гибкий и разница в скорости - константа - несколько лишних команд. Евгений, у меня несколько другая идеология.Я совершенно не понимаю людей, для которых "тормозов не замечено" является определяющим аргументом. Мне представляется, что неэффективность, даже микронная - не должна быть заложена в Язык. Язык, в моем понимании, это средство, позволяющее разработчику изложить свои мысли в виде, понятном для компилятора. Вот там можно говорить об эффективности - хорошая, плохая, очень хорошая, совершенно неприемлимая..., и т.п.. И это совершенно другой разговор. Если у компилятора достаточно информации, для генерации идеального (не меньше!!!) кода, то Язык адекватен. Сегодня не совсем эффективно - завтра поправим... если сумеем. Вот выше я обратил внимание на следующий факт: Цитата: Например, в тот момент, когда я (в смысле, разработчик) пишу строку кода (в патерне системы сообщений в КП): Тумблер3.Event := Решатель2, мне совершенно точно известно, что на самом деле мне надо попасть в метод РешитьПодумавши этого объекта. -- и это есть плохо, когда: "все знаю, все понимаю, а сказать не могу".Просто я этого сказать не могу, нету таких слов в язЫке. Сказал, как позволяет Язык - и могу быть уверен: никогда компилятор не сделает истинно оптимального кода, обязательно будет заниматься какой-нибудь "селекцией" А если смогу передать компилятору свои знания о задаче - то это будет называться выразительностью Языка И мне кажется, что уже это будет хорошо. Воспользуется компилятор этими моими знаниями, или нет - разговор тоже интересный, но другой. В общем, как-то так... |
Автор: | Galkov [ Среда, 09 Декабрь, 2009 04:00 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Сергей Губанов писал(а): Galkov писал(а): И как тогда понимать "Ну изготовьте этот тип сами если он Вам так нравится" Я показал как, привёл полный код.Нельзя сказать, что мне нравится именно procedure of object. Разве что, как следствие чего-то более фундаментального Мне нравится простота и понятность изложения своих мыслей, плюс предельная (хотя бы потенциально) эффективность реализации этих мыслей Можно сказать, что мне нравится "компьютерное Айкидо" Сергей Губанов писал(а): Ещё надо добавить, что этот указатель прячется компилятором где-то "сбоку", а не внедряется в тело объекта. О как Не, ну тут надо разъяснение обязательно просить. Вот у Ильи получается дать разъяснение "одной строкой", после которого становится понятно не менее, чем на 90% А |
Автор: | Galkov [ Среда, 09 Декабрь, 2009 04:00 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Илья Ермаков писал(а): Очень абстрактный пример. Если он возникает из САПРовых задач, где эти объекты и их соединения являются не архитектурой программы, а обрабатываемыми программой.. то логично завести какой-нибудь базовый тип Element и т.п. и уже от него плясать. Если же какая-то конкретная задача, то много вариантов может быть. У того же думателя естественно завести одну процедуру Думать и параметризовать её - как именно думать. В общем случае можно параметризовать RECORD-сообщением. Ведь думаний может быть много - не изменять же определение типа при каждом развитии программы? Ну для кого абстрактный, а для кого и суровые повседневные будни (с точностью до имен типов и методов) Пакет Дельфи в HiAsm именно такие коды и делает: каждый элемент есть представитель некого класса, определенного в отдельном модуле; левые/нижние точки - методы, а правые/верхние - события. Если абсолютно формально, есть конечно и отличия, но очень уж не принципиальные. И то, что десятки объектов могут быть связаны между собой самым нетривиальным образом - так это не просто факт. Это больше, чем факт: так оно и было на самом деле Про завести отдельный метод на все Думать... Было такое "на заре", скажем все левые точки - метод doWork, а параметризация идет отдельным аргументом/индексом. С тех пор и осталось определение типа Event (в упоминаемом в этом топике смысле) не просто как procedure of object, а как: Код: THI_Event = record Собственно, в элементе-контейнере (MultiElement) так есть и сейчас... И этот метод просто переправляет вызов дальше, осуществляя селекцию из своего массива (заполненного конструктором внутренней схемы)Event:procedure(var Data:TData; Index:word) of object; Index:word; end; А в "нормальных" элементах, заменено на прямые вызовы методов - просто так эффективнее. Ну это ладно. Такой патерн может быть универсален, только если любой чих выделять в отдельный модуль. У нас сегодня именно так - именно любой, и именно в отдельный. Посему и доходит до сотни "разъемов" на отдельной алгоритмической ветке. Кстати, о птичках... В интерфейсных алгоритмических ветках (они же - "Гуёвые callback-и") тормозов тоже не было замечено. Но они есть. Поверьте, я знаю о чем говорю Ну хорошо, давайте будем менять патерн методом "рассыпания низкоуровневых элементов на запчасти". Зинлайним их (IF, FOR, и т.п.) методы, и всего делов. Получается несколько иной патерн:
2) они предоставляют в качестве документации только "интерфейс". Какой - сейчас и подумаем 3) а разработчик (в смысле - я) пользуется только предоставленным "интерфейсом" компонентов 4) некие события оформляю уже (в смысле - в отличие от ранее представленного примера) как именно мной написанные коды, которые могут вызывать методы других объектов в порядке, вытекающем из моего понимания, чего следует делать по определенному событию. Ну и для полной ликвидации абстракций, беру совершенно конкретный (свой, естественно) пример. Постановка задачи:
2) Все они (да и не только они) подключены по линии I2C к компьютеру, который уже никакими обратными связями не занимается, а просто накачивает в них траекторию движения. I2C - не потому, что я ее сильно люблю, а потому что она аппаратно встроена в AVR-ки под именем TWI-интерфейс 3) Со стороны компьютера уже написан модуль (хоть и мной, но пусть это называется сторонний разработчик) имеющий нужные команды. Как минимум две: добавить байт в буфер; и - послать все, накопленное ранее, с префиксом-командой (тоже байт). Есть еще: установка адреса получателя, количество байт для приема ответа - но это не самое существенное. То ли это команды модуля, то ли методы единичного объекта - тоже не самое главное, зависит от отношения конкретного Языка к священной мантре типа "все есть объект" 4) В мою задачу не входит написание боевой программы для оператора технологической установки. Но мне нужен инструмент для тестирования и испытания сделанного мной же железа (типа - программирование без программистов) 5) Ну вот, для испытания модуля, мне и нужен интерфейс из всяких кнопок (включить/выключить обратную связь, накачать чего-то в буфер движения, старт движения, и т.п.), трэк-баров (например, просто подать напряжение на электродвигатель), редакторов текста (там записана траектория для накачки: точки на фазовой траектории (пары перемещение/скорость), между которыми будет происходить равноускоренное движение), и прочая мутота, которую я могу взять (предположим!!!) из некой визуальной библиотеки. Таймеры, тоже источники событий, между прочим - для опроса и индикации свободного места в буфере движения контроллеров, например. 6) Моя задача - да просто написать обработчики событий этой визуальной мутоты, которые нужным образом дадут команды "железному" модулю, пользуясь при этом данными с визуальных компонентов. Т.е., вызывая и методы этих визульных объектов - тоже. Ну и начинаю... Как самым естественным способом зафиксировать обработчик событий визуального контролла ??? Да тот же процедурный тип - нет необходимости заводить какие-то объекты в хипе. Дешево, и сердито. Дальше - вопросов нет, во всех случаях мне известно чего делать, написание кодов этих обработчиков становится чисто техническим вопросом. И вопроса стыковки сигнатур не стоит вовсе: я, при написании обработчиков, руководствуюсь просто спецификацией на визуальные контроллы. Ясно, что список аргументов процедурного типа составляли сторонние разработчики, не имея понятия о моей специфике. Все максимально эффективно пока, хотя это всего лишь первый этап. Даже все функциональные вызовы обоснованы неоднократным применением того же кода. А как здесь будет выглядеть патерн "шины сообщений" ??? Да так, что не все понятно, на самом-то деле... Кто определяет типы сообщений? По логике "каждый должен висеть за свое яйцо" - разработчик визуального контролла. Вроде бы... Кто будет приемником теперь? Мне думается, что это единый приемник на всю схему. Ну скажем, все это вместе, есть коды некого объекта... Вот егойный this - и есть объект-приемник. Кстати, установка "одинакового объекта" во все обработчики - вовсе не бессмысленна, но об этом ниже... Добавлю, что селекция уже будет не настолько "маловариантной". И ко всему этому, следует придумывать еще какую-то селекцию, кроме "типовой" - надо же как-то различать сообщения разных кнопок, которые идут с одним типом. Не исключаю, правда, что это все разрешено в каркасах ББ. Но как-то не очень верится, что БЕЗ дополнительных потерь эффективности... Даже если они и маленькие, но все равно - дополнительные. А теперь, внимание - второй этап: внезапно вспоминаем, что "железных" модулей у меня три. Ну и все нормально - называем все это визуальное безобразие отдельным объектом, а сделанные ранее сверх-оптимальные процедуры-обработчики - методами этого объекта (класса). Три таких экземпляра (скажем, зарегистрированные в табе) - и все готово. Если, конечно, у меня есть ООП-прикрытие для процедурного типа. Нет сомнений, что коллегам понятно, на какое "прикрытие" я намекаю Специально обращаю внимание, что их стало три вовсе не из-за каких-то там понтов А просто - так оно и было на самом деле. Ну а с патерном "шины сообщений" новых сложностей не возникает, и старых хватит. А вот присвоение "одинаковых" this перестает казаться глупым - теперь это три разных this-а. ______________________ Вот Вам и весь сказ |
Автор: | Илья Ермаков [ Среда, 09 Декабрь, 2009 08:08 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Galkov писал(а): Вот выше я обратил внимание на следующий факт: Цитата: Например, в тот момент, когда я (в смысле, разработчик) пишу строку кода (в патерне системы сообщений в КП): Тумблер3.Event := Решатель2, мне совершенно точно известно, что на самом деле мне надо попасть в метод РешитьПодумавши этого объекта. -- и это есть плохо, когда: "все знаю, все понимаю, а сказать не могу".Просто я этого сказать не могу, нету таких слов в язЫке. Да, то, про что Вы говорите, даже скорее не эффективности касается, а вообще статической проверки. WITH и сообщения - это прекрасно, это базовое средство для полностью динамического связывания в Обероне ("имитация Смоллтока" в тех разрезах системы, где это требуется). Но опыт Оберона предполагает, что динамика, как точка неограниченного расширения, должна закладываться только в те места, в которых это расширение запланировано ("сочленения"). А вне этих мест ("скелет") должна быть жёсткость и максимум статических проверок ("если понимаю точно, то так и могу записать, и у компилятора достаточно информации, чтобы меня проверить" (С) почти Вы). Так что обсуждаемая тема точно имеет смысл. Процедурные переменные в системных вещах используются (и будут использоваться) достаточно интенсивно, хотя бы по той причине, что использование GC там локализуется во времени-пространстве (создали архитектурные объекты - соединили, изредка пересоединяем), и "массовая" память управляется по-другому (например, viewtopic.php?f=2&t=2006). Переход же от одного модуля к нескольким экземплярам типа - вполне частая операция (вместо модуля - этакие "микромодули"). Иметь процедурные указатели к таким "микромодулям" - тоже естественно. |
Автор: | Евгений Темиргалеев [ Среда, 09 Декабрь, 2009 12:20 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Galkov писал(а): Сергей Губанов писал(а): Ещё надо добавить, что этот указатель прячется компилятором где-то "сбоку", а не внедряется в тело объекта. О как Не, ну тут надо разъяснение обязательно просить. Вот у Ильи получается дать разъяснение "одной строкой", после которого становится понятно не менее, чем на 90% А P.S. Илья разбирался не ради простого интереса, а когда делал Active BlackBox. http://oberoncore.ru/blackbox/polygon |
Автор: | Евгений Темиргалеев [ Среда, 09 Декабрь, 2009 12:23 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Galkov писал(а): Евгений Темиргалеев писал(а): В каких задачах эта эффективность даст такие плюсы, чтобы нужно было включать в язык? Это учитывая что ББ-й механизм с сообщениями более гибкий и разница в скорости - константа - несколько лишних команд. Евгений, у меня несколько другая идеология.Я совершенно не понимаю людей, для которых "тормозов не замечено" является определяющим аргументом. |
Автор: | Valery Solovey [ Среда, 09 Декабрь, 2009 13:06 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Galkov писал(а): ... Вы перестание комплексовать по поводу того, что кто-то обижает Обероны. Оберон здесь ни причём. Вы аргументируете пользу procedure of object словами, которые лишены всякого смысла.>я совершено не понял Вашего вопроса: что значит "как" Слово "как" объяснено в указанных далее 4-х пунктах. То, что Вы назваете дополнительными потерями является следствием получаемой гибкости программы. Если Вы это исключаете из своего проекта, то Вы лишаетесь гибкости. С одной стороны, гибкость не везде нужна, с другой - не говорите потом, что она есть. >А теперь, внимание - второй этап: внезапно вспоминаем, что "железных" модулей у меня три. Вот появляется потребность переместиться по вертикали. Неужели Вы для этого случая не селектируете объекты? Какой по вертикали, какие по горизонтали. >Специально обращаю внимание, что их стало три вовсе не из-за каких-то там понтов Это было сказано на правах шутки. А смысл был в другом: Вы всё равно выбираете сами. До или после. Этот момент присутствует в любой программе. А следовательно нельзя называть этот пункт недостатком: ваш подход его не нивелирует. Поэтому слова вроде "подход плох, потому что заставляет селектировать" (утрирую) и лишены смысла. |
Автор: | Galkov [ Среда, 09 Декабрь, 2009 15:08 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Евгений Темиргалеев писал(а): Большинсто пока и без этого ядрёного знания особенностей реализации со своими задачами справляются Евгений, я дико извиняюсь, конечно же, но БОЛЬШИНСТВО, вообще не очень образовано.И то, чем пользуется по жизни это большинство, сделано неким меньшинством Это я про то, что меня очень удивляет Ваш способ аргументации. Евгений Темиргалеев писал(а): Для меня определяющим является лозунг "долой преждевременную оптимизацию" Мне казалось, что речь шла не о преждевременной, а о принципиально недостижимой оптимизации.Это две большие разницы Ну и фиг с ней, с принципиально достижимой ??? Соглашусь, большинству - пофиг на качество получаемого продукта. Но только эффективность результата - это тоже показатель назначения системы программирования. Да-да, не только читаемость кодов, не только работоспособность результата, и не только надежность кодинга. А хорошая и качественно сделанная система - совмещает все показатели, а не один в ущерб другому. Разве кто-то показал, что вышеупомянутая "деталька" вошла в противоречие с вышеупомянутым Или дает избыточность в изложении одной и той же мысли Нет. Лозунги вместо логики пока были. Из серии: "да зачем тебе это надо, и так все работает" Евгений Темиргалеев писал(а): а пример задачи Вы так и не привели - где эта оптимизация будет оправдана Что еще следует привести, прости господи... Конкретные коды ???Это возможно, задачка решена сто лет назад. Могу на Дельфи, могу на asm-е. Можно на C++ методами читерства. Если я знаю, чего надо делать, то Язык - на самая значительная техническая подробность. Если он обладает достаточной выразительностью. А на КП - не могу, с той же эффективностью А вот решить на КП эту задачу же в другом патерне - могу, но с меньшей эффективностью. Что языковые средства полны - никаких возражений нет, задачу решить можно. Да и с точки зрения дизайна (читаемость, понимаемость, ...), таковое решение не кажется мне шедевром, если честно... |
Автор: | Galkov [ Среда, 09 Декабрь, 2009 15:12 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Valery Solovey писал(а): Вы аргументируете пользу procedure of object словами, которые лишены всякого смысла Ну значит у Вас проблемы с пониманием смысла.Мои поздравления, можете не знать что ухо можно и рукой почесать - и будете жить счастливо DIXI |
Автор: | Евгений Темиргалеев [ Среда, 09 Декабрь, 2009 16:06 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Galkov писал(а): Евгений Темиргалеев писал(а): Для меня определяющим является лозунг "долой преждевременную оптимизацию" Мне казалось, что речь шла не о преждевременной, а о принципиально недостижимой оптимизации.Это две большие разницы Ну и фиг с ней, с принципиально достижимой ??? Соглашусь, большинству - пофиг на качество получаемого продукта. 2) Принципиально достижима - см. ниже. Galkov писал(а): Евгений Темиргалеев писал(а): а пример задачи Вы так и не привели - где эта оптимизация будет оправдана Что еще следует привести, прости господи... ... А на КП - не могу, с той же эффективностью. А вот решить на КП эту задачу же в другом патерне - могу, но с меньшей эффективностью. Тогда бы можно было бы говорить о большей выразительности "procedure of object" как языкового средства. И сетовать об отсутствии этого средства в КП - при условии повседневности таких задач. P.S: примеры задач Вы приводить не обязаны. Просто думаю, что считать Ваши утверждения имеющими смысл с практической точки зрения можно только если такие задачи есть. |
Автор: | Axcel [ Среда, 09 Декабрь, 2009 18:14 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Господа, может я чего то не понимаю, но до сих пор я считал, что основное назначение (в Delphi) procedure of object, это основа для обработчиков событий, а именно: type TNotifyEvent = procedure (Sender: TObject) of object; Но если это так, то исчерпывающий ответ почему в ББ это не используется дан здесь http://store.oberoncore.ru/lib/article/DesignIdeas.pdf в разделе 2. родовые шины сообщений (generic message buses); |
Автор: | Galkov [ Вторник, 15 Декабрь, 2009 23:39 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Писал было много... а потом плюнул, и решил оставить просто пару замечаний на уровне выводов 1) Парадигма из серии "предъявите пример, чтобы мне показалось..." - это вообще, не для людей мыслящих. Если хочешь кого-то послать - самое то. А если сделать Дело - и рядом с разработчиками и не стояла. Они (разработчики) пользуются несколько иными правилами принятия решений. 2) Все изменения, внесенные разработчиками КП в базовый Оберон, не проходят через сито: "неприемлемо медленно" и "при условии повседневности таких задач" Т.е., procedure of object - не в самой плохой компании. 3) Обращать внимание на то, что приведенный пример, это просто пример универсального патерна превращения комбинации компонентов в новый единый компонент - не очень разумно, видимо, в свете вышесказанного. Универсального до такой степени, что там могут оказаться и "числодробительные" алгоритмы. 4) Про то, что некое большинство не интересуется "ядерными проблемами", и живет счастливо. Напомню, что термин невежество относится вовсе не к тем, кто чего-то еще не знает. Но к тем, кто знать этого не желает Зачем я про это? Может к Вам зайти некий новый пользователь, а Вы ему дадите "совет большинства". Самая типовая реакция умного человека: ничего не скажет (скажем, воспитание не позволит), но сделет вывод обо всем Оберон-сообществе. |
Автор: | Рыжий [ Четверг, 25 Февраль, 2010 17:01 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Я все понял, я только не понял вот как мне - "метод класса" соорудить. Пусть у меня есть какая-то: pointer to record с методом, я создаю экземпляры new,как мне метод от них отвязать;И подстановку как в делфи of object та потому для событий рулит что ети события - методы формы, как методы класса. |
Автор: | Galkov [ Четверг, 09 Декабрь, 2010 11:07 ] |
Заголовок сообщения: | Re: Хуки или шина - вот в чём вопрос! |
Перенесено из: viewtopic.php?p=55370#p55370 Вообще-то, при обсуждении procedure of object, мне объяснили, что в Обероне и первого не дано. Только второе Хочешь подключить адресата сообщений? Пожалуйста, вот тебе поле для указателя на объект, наследующий (переопределяющий) handle. А всякие там procedure of object (которые и есть быстрая связь напрямую) - от лукавого. Родовыми же сообщениями задачу можно ведь решить Это не моя точка зрения, это мне так объяснили. |
Автор: | Galkov [ Четверг, 09 Декабрь, 2010 11:53 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Мне думается, что если сие в этом топике, то правильнее привести цитату: Info21 писал(а): Итого, в системе управления организма есть аналоги как прямых вызовов (прямые нервные связи), так и шины сообщений (гормоны в крови). Как забавно. Можно сказать, третьего не дано btw: Еще правильнее ее было бы разместить в начале предыдущего поста, но мне почему-то редактировать его не дано |
Автор: | Info21 [ Четверг, 09 Декабрь, 2010 14:35 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
А мысль-то в чем? Есть методы -- прямая связь. Есть сообщения -- шина/гормоны. Есть, в конце концов, банальные процедурные переменные, которые можно хранить в полях и менять. Как GOTO, из которого можно слепить что угодно, если не хватит первых двух. |
Автор: | Galkov [ Четверг, 09 Декабрь, 2010 15:12 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
А, Вы к "нервным связям" относите "неразъемные" вызовы методов... Недосмотрел. А мысль в том, что мне как раз нервными связями представлялись процедурные переменные, НО расширенные на ООП (без разницы какое название - сигналы, PrOfObj...). Предположим на такой, где процедур вообще нет (а те, что были, стали методами некого глобального контекста), а есть только методы. Вот и подумал - так где же они... Можно, конечно же, только и на гормональной связи - но ведь даже Природе их не хватило. |
Автор: | Info21 [ Четверг, 09 Декабрь, 2010 19:42 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Galkov писал(а): А, Вы к "нервным связям" относите "неразъемные" вызовы методов... Нет. Я к нервным связям отнес бы вызовы процедур.А методы и процедурные переменные -- это некий промежуточный случай. Ну так и в ЦНС восприимчивость к прямому сигналу модулируется гуморальным состоянием. В любом случае это промежуточный вариант, а не нечто новое. |
Страница 3 из 9 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |