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 - абсолютно в стиле тех деталек, которые привнесены КП в классический Оберон.
Просто про нее
позабыли, и оставили исходный процедурный тип (где-то слышал, что это один из трех китов классического Оберона) без ООП-прикрытия.
Незаслуженно, причем