OberonCore

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

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




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

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Как бы мне следует принести извинения, что не так оперативно отвечаю.......
Но ответить хочется, причем - сильно подумавши. А это требует времени, которое получается "отложенным".
Ну дык я собрался :)


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

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
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 - абсолютно в стиле тех деталек, которые привнесены КП в классический Оберон.
Просто про нее позабыли, и оставили исходный процедурный тип (где-то слышал, что это один из трех китов классического Оберона) без ООП-прикрытия.

Незаслуженно, причем :)


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

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

Вот выше я обратил внимание на следующий факт:
Цитата:
Например, в тот момент, когда я (в смысле, разработчик) пишу строку кода (в патерне системы сообщений в КП): Тумблер3.Event := Решатель2, мне совершенно точно известно, что на самом деле мне надо попасть в метод РешитьПодумавши этого объекта.
Просто я этого сказать не могу, нету таких слов в язЫке.
-- и это есть плохо, когда: "все знаю, все понимаю, а сказать не могу".
Сказал, как позволяет Язык - и могу быть уверен: никогда компилятор не сделает истинно оптимального кода, обязательно будет заниматься какой-нибудь "селекцией"
А если смогу передать компилятору свои знания о задаче - то это будет называться выразительностью Языка
И мне кажется, что уже это будет хорошо. Воспользуется компилятор этими моими знаниями, или нет - разговор тоже интересный, но другой.

В общем, как-то так... :)


Последний раз редактировалось Galkov Среда, 09 Декабрь, 2009 04:28, всего редактировалось 1 раз.

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

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Сергей Губанов писал(а):
Galkov писал(а):
И как тогда понимать "Ну изготовьте этот тип сами если он Вам так нравится" :?:
Я показал как, привёл полный код.
Ну значит у нас какое-то непонимание приключилось :)
Нельзя сказать, что мне нравится именно procedure of object. Разве что, как следствие чего-то более фундаментального
Мне нравится простота и понятность изложения своих мыслей, плюс предельная (хотя бы потенциально) эффективность реализации этих мыслей
Можно сказать, что мне нравится "компьютерное Айкидо" :)


Сергей Губанов писал(а):
Ещё надо добавить, что этот указатель прячется компилятором где-то "сбоку", а не внедряется в тело объекта.
О как :roll:
Не, ну тут надо разъяснение обязательно просить.
Вот у Ильи получается дать разъяснение "одной строкой", после которого становится понятно не менее, чем на 90%
А :?: :)


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

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

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

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

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

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

Про завести отдельный метод на все Думать...
Было такое "на заре", скажем все левые точки - метод doWork, а параметризация идет отдельным аргументом/индексом.
С тех пор и осталось определение типа Event (в упоминаемом в этом топике смысле) не просто как procedure of object, а как:
Код:
  THI_Event = record
    Event:procedure(var Data:TData; Index:word) of object;
    Index:word;
  end;
Собственно, в элементе-контейнере (MultiElement) так есть и сейчас... И этот метод просто переправляет вызов дальше, осуществляя селекцию из своего массива (заполненного конструктором внутренней схемы)
А в "нормальных" элементах, заменено на прямые вызовы методов - просто так эффективнее.

Ну это ладно. Такой патерн может быть универсален, только если любой чих выделять в отдельный модуль.
У нас сегодня именно так - именно любой, и именно в отдельный. Посему и доходит до сотни "разъемов" на отдельной алгоритмической ветке.
Кстати, о птичках... В интерфейсных алгоритмических ветках (они же - "Гуёвые callback-и") тормозов тоже не было замечено. Но они есть. Поверьте, я знаю о чем говорю :)


Ну хорошо, давайте будем менять патерн методом "рассыпания низкоуровневых элементов на запчасти". Зинлайним их (IF, FOR, и т.п.) методы, и всего делов.
Получается несколько иной патерн:
    1) некоторую элементную (читай - компонентную) базу делают сторонние разработчики
    2) они предоставляют в качестве документации только "интерфейс". Какой - сейчас и подумаем
    3) а разработчик (в смысле - я) пользуется только предоставленным "интерфейсом" компонентов
    4) некие события оформляю уже (в смысле - в отличие от ранее представленного примера) как именно мной написанные коды, которые могут вызывать методы других объектов в порядке, вытекающем из моего понимания, чего следует делать по определенному событию.

Ну и для полной ликвидации абстракций, беру совершенно конкретный (свой, естественно) пример.
Постановка задачи:
    1) Разработал я некий привод координатного стола. Упрощенно: три (по одному на координату) одинаковых модуля, осуществляющие обратную связь с датчика перемещений (ЛИР-350 Z=3600) на электродвигатель постоянного тока (марку на ходу не вспомню - 150 ватт/30 Вольт).
    2) Все они (да и не только они) подключены по линии I2C к компьютеру, который уже никакими обратными связями не занимается, а просто накачивает в них траекторию движения. I2C - не потому, что я ее сильно люблю, а потому что она аппаратно встроена в AVR-ки под именем TWI-интерфейс
    3) Со стороны компьютера уже написан модуль (хоть и мной, но пусть это называется сторонний разработчик) имеющий нужные команды. Как минимум две: добавить байт в буфер; и - послать все, накопленное ранее, с префиксом-командой (тоже байт). Есть еще: установка адреса получателя, количество байт для приема ответа - но это не самое существенное. То ли это команды модуля, то ли методы единичного объекта - тоже не самое главное, зависит от отношения конкретного Языка к священной мантре типа "все есть объект"
    4) В мою задачу не входит написание боевой программы для оператора технологической установки. Но мне нужен инструмент для тестирования и испытания сделанного мной же железа (типа - программирование без программистов)
    5) Ну вот, для испытания модуля, мне и нужен интерфейс из всяких кнопок (включить/выключить обратную связь, накачать чего-то в буфер движения, старт движения, и т.п.), трэк-баров (например, просто подать напряжение на электродвигатель), редакторов текста (там записана траектория для накачки: точки на фазовой траектории (пары перемещение/скорость), между которыми будет происходить равноускоренное движение), и прочая мутота, которую я могу взять (предположим!!!) из некой визуальной библиотеки. Таймеры, тоже источники событий, между прочим - для опроса и индикации свободного места в буфере движения контроллеров, например.
    6) Моя задача - да просто написать обработчики событий этой визуальной мутоты, которые нужным образом дадут команды "железному" модулю, пользуясь при этом данными с визуальных компонентов. Т.е., вызывая и методы этих визульных объектов - тоже.

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

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

А теперь, внимание - второй этап: внезапно вспоминаем, что "железных" модулей у меня три.
Ну и все нормально - называем все это визуальное безобразие отдельным объектом, а сделанные ранее сверх-оптимальные процедуры-обработчики - методами этого объекта (класса).
Три таких экземпляра (скажем, зарегистрированные в табе) - и все готово. Если, конечно, у меня есть ООП-прикрытие для процедурного типа.
Нет сомнений, что коллегам понятно, на какое "прикрытие" я намекаю 8)
Специально обращаю внимание, что их стало три вовсе не из-за каких-то там понтов :P
А просто - так оно и было на самом деле.

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

______________________

Вот Вам и весь сказ :)


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

Зарегистрирован: Понедельник, 14 Ноябрь, 2005 18:39
Сообщения: 9459
Откуда: Россия, Орёл
Galkov писал(а):
Вот выше я обратил внимание на следующий факт:
Цитата:
Например, в тот момент, когда я (в смысле, разработчик) пишу строку кода (в патерне системы сообщений в КП): Тумблер3.Event := Решатель2, мне совершенно точно известно, что на самом деле мне надо попасть в метод РешитьПодумавши этого объекта.
Просто я этого сказать не могу, нету таких слов в язЫке.
-- и это есть плохо, когда: "все знаю, все понимаю, а сказать не могу".


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

Так что обсуждаемая тема точно имеет смысл.

Процедурные переменные в системных вещах используются (и будут использоваться) достаточно интенсивно, хотя бы по той причине, что использование GC там локализуется во времени-пространстве (создали архитектурные объекты - соединили, изредка пересоединяем), и "массовая" память управляется по-другому (например, viewtopic.php?f=2&t=2006). Переход же от одного модуля к нескольким экземплярам типа - вполне частая операция (вместо модуля - этакие "микромодули"). Иметь процедурные указатели к таким "микромодулям" - тоже естественно.


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Galkov писал(а):
Сергей Губанов писал(а):
Ещё надо добавить, что этот указатель прячется компилятором где-то "сбоку", а не внедряется в тело объекта.
О как :roll:
Не, ну тут надо разъяснение обязательно просить.
Вот у Ильи получается дать разъяснение "одной строкой", после которого становится понятно не менее, чем на 90%
А :?: :)
"Вот у Ильи получается" потому что он разбирался в исходниках Kernel, где эти вещи прокомментированы. И составил описание: http://oberoncore.ru/wiki/blackbox/kernel. Так что можно "разъяснение обязательно просить", а можно и самому почитать комментарии-описание, ежели так интересно. Большинсто пока и без этого ядрёного знания особенностей реализации со своими задачами справляются.

P.S. Илья разбирался не ради простого интереса, а когда делал Active BlackBox. http://oberoncore.ru/blackbox/polygon


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Galkov писал(а):
Евгений Темиргалеев писал(а):
В каких задачах эта эффективность даст такие плюсы, чтобы нужно было включать в язык? Это учитывая что ББ-й механизм с сообщениями более гибкий и разница в скорости - константа - несколько лишних команд.
Евгений, у меня несколько другая идеология.
Я совершенно не понимаю людей, для которых "тормозов не замечено" является определяющим аргументом.
Для меня определяющим является лозунг "долой преждевременную оптимизацию"... а пример задачи Вы так и не привели - где эта оптимизация будет оправдана.


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

Зарегистрирован: Понедельник, 30 Июль, 2007 10:53
Сообщения: 1538
Откуда: Беларусь, Минск
Galkov писал(а):
... Вы перестание комплексовать по поводу того, что кто-то обижает Обероны.
Оберон здесь ни причём. Вы аргументируете пользу procedure of object словами, которые лишены всякого смысла.

>я совершено не понял Вашего вопроса: что значит "как"
Слово "как" объяснено в указанных далее 4-х пунктах.

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

>А теперь, внимание - второй этап: внезапно вспоминаем, что "железных" модулей у меня три.
Вот появляется потребность переместиться по вертикали. Неужели Вы для этого случая не селектируете объекты? Какой по вертикали, какие по горизонтали.

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


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

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Евгений Темиргалеев писал(а):
Большинсто пока и без этого ядрёного знания особенностей реализации со своими задачами справляются
Евгений, я дико извиняюсь, конечно же, но БОЛЬШИНСТВО, вообще не очень образовано.
И то, чем пользуется по жизни это большинство, сделано неким меньшинством
Это я про то, что меня очень удивляет Ваш способ аргументации.

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

Евгений Темиргалеев писал(а):
а пример задачи Вы так и не привели - где эта оптимизация будет оправдана
Что еще следует привести, прости господи... Конкретные коды ???
Это возможно, задачка решена сто лет назад. Могу на Дельфи, могу на asm-е. Можно на C++ методами читерства.
Если я знаю, чего надо делать, то Язык - на самая значительная техническая подробность. Если он обладает достаточной выразительностью.
А на КП - не могу, с той же эффективностью
А вот решить на КП эту задачу же в другом патерне - могу, но с меньшей эффективностью. Что языковые средства полны - никаких возражений нет, задачу решить можно.
Да и с точки зрения дизайна (читаемость, понимаемость, ...), таковое решение не кажется мне шедевром, если честно...


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

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Valery Solovey писал(а):
Вы аргументируете пользу procedure of object словами, которые лишены всякого смысла
Ну значит у Вас проблемы с пониманием смысла.
Мои поздравления, можете не знать что ухо можно и рукой почесать - и будете жить счастливо
DIXI


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

Зарегистрирован: Среда, 16 Ноябрь, 2005 00:53
Сообщения: 4625
Откуда: Россия, Орёл
Galkov писал(а):
Евгений Темиргалеев писал(а):
Для меня определяющим является лозунг "долой преждевременную оптимизацию"
Мне казалось, что речь шла не о преждевременной, а о принципиально недостижимой оптимизации.
Это две большие разницы
Ну и фиг с ней, с принципиально достижимой ???
Соглашусь, большинству - пофиг на качество получаемого продукта.
1) Не думаю, что это можно сказать о большинстве пользователей ББ. Которые не интересуются ядерными подробностями до возникновения необходимости.
2) Принципиально достижима - см. ниже.
Galkov писал(а):
Евгений Темиргалеев писал(а):
а пример задачи Вы так и не привели - где эта оптимизация будет оправдана
Что еще следует привести, прости господи...
...
А на КП - не могу, с той же эффективностью. А вот решить на КП эту задачу же в другом патерне - могу, но с меньшей эффективностью.
Хотелось бы увидеть пример задачи, для которой предложенное решение на КП с сообщениями работало бы непримемлемо медленно и пришлось бы использовать особые средства оптимизации. Например, кодовые процедуры ("асм") для реализации прямого аналога "procedure of object".

Тогда бы можно было бы говорить о большей выразительности "procedure of object" как языкового средства. И сетовать об отсутствии этого средства в КП - при условии повседневности таких задач.

P.S: примеры задач Вы приводить не обязаны. Просто думаю, что считать Ваши утверждения имеющими смысл с практической точки зрения можно только если такие задачи есть.


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

Зарегистрирован: Понедельник, 05 Июнь, 2006 09:49
Сообщения: 327
Откуда: Ленинград, Емельянов Алексей Николаевич
Господа, может я чего то не понимаю, но до сих пор я считал, что основное назначение (в Delphi) procedure of object, это основа для обработчиков событий, а именно: type TNotifyEvent = procedure (Sender: TObject) of object;

Но если это так, то исчерпывающий ответ почему в ББ это не используется дан здесь http://store.oberoncore.ru/lib/article/DesignIdeas.pdf в разделе 2. родовые шины сообщений (generic message buses);


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

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Писал было много... а потом плюнул, и решил оставить просто пару замечаний на уровне выводов

1) Парадигма из серии "предъявите пример, чтобы мне показалось..." - это вообще, не для людей мыслящих. Если хочешь кого-то послать - самое то. А если сделать Дело - и рядом с разработчиками и не стояла. Они (разработчики) пользуются несколько иными правилами принятия решений.

2) Все изменения, внесенные разработчиками КП в базовый Оберон, не проходят через сито: "неприемлемо медленно" и "при условии повседневности таких задач"
Т.е., procedure of object - не в самой плохой компании.

3) Обращать внимание на то, что приведенный пример, это просто пример универсального патерна превращения комбинации компонентов в новый единый компонент - не очень разумно, видимо, в свете вышесказанного.
Универсального до такой степени, что там могут оказаться и "числодробительные" алгоритмы.

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


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

Зарегистрирован: Вторник, 05 Январь, 2010 21:31
Сообщения: 1101
Откуда: Харків, Данилівка
Я все понял, я только не понял вот как мне - "метод класса" соорудить.
Пусть у меня есть какая-то: pointer to record с методом, я создаю экземпляры new,как мне метод от них отвязать;И подстановку как в делфи of object та потому для событий рулит что ети события - методы формы, как методы класса. :(


Вернуться к началу
 Профиль  
 
 Заголовок сообщения: Re: Хуки или шина - вот в чём вопрос!
СообщениеДобавлено: Четверг, 09 Декабрь, 2010 11:07 

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Перенесено из: viewtopic.php?p=55370#p55370

Вообще-то, при обсуждении procedure of object, мне объяснили, что в Обероне и первого не дано. Только второе
Хочешь подключить адресата сообщений? Пожалуйста, вот тебе поле для указателя на объект, наследующий (переопределяющий) handle.

А всякие там procedure of object (которые и есть быстрая связь напрямую) - от лукавого. Родовыми же сообщениями задачу можно ведь решить :wink:

Это не моя точка зрения, это мне так объяснили.


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

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
Мне думается, что если сие в этом топике, то правильнее привести цитату:
Info21 писал(а):
Итого, в системе управления организма есть аналоги как прямых вызовов (прямые нервные связи), так и шины сообщений (гормоны в крови).

Как забавно.
Можно сказать, третьего не дано :)


btw: Еще правильнее ее было бы разместить в начале предыдущего поста, но мне почему-то редактировать его не дано


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
А мысль-то в чем?
Есть методы -- прямая связь.
Есть сообщения -- шина/гормоны.

Есть, в конце концов, банальные процедурные переменные, которые можно хранить в полях и менять. Как GOTO, из которого можно слепить что угодно, если не хватит первых двух.


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

Зарегистрирован: Вторник, 11 Август, 2009 11:44
Сообщения: 516
Откуда: Бердск
А, Вы к "нервным связям" относите "неразъемные" вызовы методов...
Недосмотрел.

А мысль в том, что мне как раз нервными связями представлялись процедурные переменные, НО расширенные на ООП (без разницы какое название - сигналы, PrOfObj...). Предположим на такой, где процедур вообще нет (а те, что были, стали методами некого глобального контекста), а есть только методы.

Вот и подумал - так где же они... Можно, конечно же, только и на гормональной связи - но ведь даже Природе их не хватило.


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

Зарегистрирован: Пятница, 25 Ноябрь, 2005 12:02
Сообщения: 8500
Откуда: Троицк, Москва
Galkov писал(а):
А, Вы к "нервным связям" относите "неразъемные" вызовы методов...
Нет. Я к нервным связям отнес бы вызовы процедур.
А методы и процедурные переменные -- это некий промежуточный случай.

Ну так и в ЦНС восприимчивость к прямому сигналу модулируется гуморальным состоянием. В любом случае это промежуточный вариант, а не нечто новое.


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

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


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

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


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

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