OberonCore https://forum.oberoncore.ru/ |
|
Аналог procedure of object в КП https://forum.oberoncore.ru/viewtopic.php?f=29&t=2125 |
Страница 8 из 9 |
Автор: | Евгений Темиргалеев [ Четверг, 23 Декабрь, 2010 13:23 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Тема и так раздута. Оффтопы режутся. |
Автор: | Galkov [ Четверг, 23 Декабрь, 2010 14:05 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Geniepro писал(а): Александр, да у Вас прямо талант объяснять! Я наконец понял о чём чешут языками в этой теме... Попробую внести свои 5 копеек. На более абстрактном уровне, которой мне ближе и понятнее. Тешу себя надеждой, что и Вас (а вдруг).Есть процедурный тип. Очень удобная штука в процедурном программировании. Оказывается, наступает эра ООП. Отчего-то нормальным людям оказывается проще формулировать свои мысли в этой парадигме... Не будем обсуждать в этом топике, примем это как экспериментальный факт, как бы это не было противно окружающим. И чего получается - удобство процедурного типа пошло псу под хвост. Обыдно, да ??? Смотрите на КП - тип есть, а нам дают в интерфейсе связанные процедуры, например. И хучь в ухо мочись - никуда ты их не засунешь. Выход конечно же есть: не получается почесать ухо рукой, можно и ногой. Типа "проблема решена". Решена еще в паттернах от банды 4-х. Называется паттерн Command. Существует другое решение проблемы - она изложена как цитата из Мюллера. Коротко, понятно, ни одной новой сущности. (BTW: в дисере Мюллера слово DELEGATE не встречается вообще. Предполагаю, народ подумал, и сказал: "да нафиг оно нужно...") Мое мнение - позволяющее создавать более прозрачный и надежный код в парадигме ООП. Конечно же, присвоить, чтобы тут же снова вызвать - не особо и нужно. Так же как и процедурный тип нафиг не нужен только чтобы тут же вызвать.И Ваши сомнения из серии "а нафига" - совершенно справедливы. Нужны эти типы для придания каких-то полиморфных средств некому методу (объекту). А вовсе не для того, чтобы: "кинеся, а воно Е" В процедурном программировании процедура сортировки, параметризированная процедурным типом сравнения становится более универсальной. Типа это и есть огромное удобство процедурного типа. В ООП, та же функция сравнения захочет знать над каким объектом она сравнивает-то. Грубо говоря, сравнение - это метод какого-то объекта, и таковых объектов может больше одного (ну надо же). Это не буйство фантазии, это реальная жизнь - уже захотели, смотрим в MSDN описание LVM_SORTITEMS Message. Ну вот и все, по мнению Ильи - "по отдельности" все в порядке будет. А по моему - некрасивые самолеты не летают. Ну или (по мнению прапорщика из анекдота) - летают, но низко-низко Об этом и разговор. |
Автор: | Илья Ермаков [ Четверг, 23 Декабрь, 2010 14:16 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Galkov писал(а): Оказывается, наступает эра ООП. Отчего-то нормальным людям оказывается проще формулировать свои мысли в этой парадигме... Не будем обсуждать в этом топике, примем это как экспериментальный факт, как бы это не было противно окружающим. Нет никакой "эры" и никакого "ООП". Есть механизмы расширения, полиморфизма, позднего связывания. МЕХАНИЗМЫ. Лучше, если они представлены по отдельности, а не едино и с "комфортом". Цитата: И чего получается - удобство процедурного типа пошло псу под хвост. Обыдно, да ??? И никто не думает об "удобствах" процедурного типа, и куда оно там пошло. Есть механизм. Просто механизм. В его задачи обеспечивать какой-то там комфорт не входит. В задачи механизма входит: - работать простым и предсказуемым образом; - быть применимым в как можно большем числе задач. Удобно или не совсем удобно - неважно. Делегаты по сравнению с процедурными переменными по первому пункту точно такие же, а по второму - применимы в гораздо меньшем числе случаев. Т.е. остаётся только критерий удобства. Но он неинтересен. Цитата: В процедурном программировании процедура сортировки, параметризированная процедурным типом сравнения становится более универсальной. Типа это и есть огромное удобство процедурного типа. Как раз дурной пример - попытки обобщать алгоритмы (начиная от параметров процедурного типа и кончая библиотеками шаблонов) - плохая затея. С нашей, конечно, точки зрения. Контейнеры и обобщённые алгоритмы, есть у меня такое убеждение, малополезны. Цитата: В ООП, та же функция сравнения захочет знать над каким объектом она сравнивает-то. Грубо говоря, сравнение - это метод какого-то объекта, и таковых объектов может больше одного (ну надо же). Это не буйство фантазии, это реальная жизнь - уже захотели, смотрим в MSDN описание LVM_SORTITEMS Message. Ну вот и все, по мнению Ильи - "по отдельности" все в порядке будет. Вот в том-то и беда - что "уже захотели". А я не хочу, чтобы функция сравнения чего-то там знала. Не хочу читать код, где она будет такой "умной". И не хочу выслушивать критику, что в мире моих инструментов функции сравнения ничего "не знают". Потому что и не нужно им знать, этим сравнениям. Цитата: А по моему - некрасивые самолеты не летают. Ну или (по мнению прапорщика из анекдота) - летают, но низко-низко Критерий красоты "вообще" - не имеет смысла. Бывает красота как следствие действительно удачности. Но это только следствие, а никак не причина. C++ тоже красивым можно назвать, как абстрактно рассматриваемый изыск в области формальных текстов. Я НЕ считаю его НЕкрасивым, например. |
Автор: | Peter Almazov [ Четверг, 23 Декабрь, 2010 14:21 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Galkov писал(а): Об этом и разговор. Вы вывод-то сформулируйте. А то разговор есть, но непонятно куда он ведет.
|
Автор: | Galkov [ Четверг, 23 Декабрь, 2010 14:47 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Дык я уже давно сформулировал... Вон Илья пишет: Цитата: - работать простым и предсказуемым образом; - быть применимым в как можно большем числе задач Есть два кода, сравнивайте. Без громких слов про "механизмы", и т.п.. Мне кажется, что код Ильи будет работать менее простым и предсказуемым образом. И применим в меньшем числе задач. Если кто-то видит черное – белым, настаивать не буду. Указанную "ненадежность" заталкивать в рот - тоже. Хватит и того, что разжевано. Не то, чтобы в лом - меня не устраивает предложенный стиль. Для меня топик был полезным в двух аспектах. Что мне стали понятны истинные мотивы использования высокоумных словов на форуме. И что Оберон - это не только КП. Грубо говоря, стиль применения Окамма и Калашникова, излагаемый на форуме, не есть характерная черта именно Оберонов. Что радует. Потому что изюминка-то в Оберонах есть. |
Автор: | Александр Шостак [ Четверг, 23 Декабрь, 2010 15:01 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Цитата: Как раз дурной пример - попытки обобщать алгоритмы (начиная от параметров процедурного типа и кончая библиотеками шаблонов) - плохая затея. С нашей, конечно, точки зрения. Контейнеры и обобщённые алгоритмы, есть у меня такое убеждение, малополезны. Илья, не могли бы вы в свободное время объяснить почему? Потому как интуитивно такой вывод определённо не напрашивается. И почему каждый раз, когда нам нужен список, мы должны его вручную под конкретный тип данных писать? Причём, так как это утомительно, выйдет он не приличным, как в Делфи TList, а примитивным линейным с последовательным доступом. |
Автор: | Info21 [ Четверг, 23 Декабрь, 2010 15:08 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Александр Ильин писал(а): Битва о том, надо ли в языке иметь процедурный тип, указывающий не только на простые глобальные процедуры, но и на на связанные с типом (т.е. методы). Вот! Спасибо. Теперь понял окончательно, что херня.
|
Автор: | Axcel [ Четверг, 23 Декабрь, 2010 16:16 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Berserker писал(а): Цитата: Как раз дурной пример - попытки обобщать алгоритмы (начиная от параметров процедурного типа и кончая библиотеками шаблонов) - плохая затея. С нашей, конечно, точки зрения. Контейнеры и обобщённые алгоритмы, есть у меня такое убеждение, малополезны. Илья, не могли бы вы в свободное время объяснить почему? Потому как интуитивно такой вывод определённо не напрашивается. И почему каждый раз, когда нам нужен список, мы должны его вручную под конкретный тип данных писать? Причём, так как это утомительно, выйдет он не приличным, как в Делфи TList, а примитивным линейным с последовательным доступом. Я об этом тоже в последнее время много думал. Но пришел к противоположному выводу. Мой личный опыт показывает, что в 99% я использую TList как "примитивный и линейный", а в оставшемся 1%, "приличность" TList мне ничего не дает, приходится прикручивать, что-то свое. Ну и ... |
Автор: | Сергей Прохоренко [ Четверг, 23 Декабрь, 2010 18:30 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Info21 писал(а): Александр Ильин писал(а): Битва о том, надо ли в языке иметь процедурный тип, указывающий не только на простые глобальные процедуры, но и на на связанные с типом (т.е. методы). Вот! Спасибо. Теперь понял окончательно, что херня.Правильно ли я понимаю, что Oberon-2 с его ООП "как у всех" (т.е. интерфейс-класс-объект) - это тупиковая ветвь эволюции оберонов? |
Автор: | Александр Шостак [ Четверг, 23 Декабрь, 2010 19:24 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Удалено модератором. Axcel писал(а): Я об этом тоже в последнее время много думал. Но пришел к противоположному выводу. Мой личный опыт показывает, что в 99% я использую TList как "примитивный и линейный", а в оставшемся 1%, "приличность" TList мне ничего не дает, приходится прикручивать, что-то свое. Ну и ... От списка нужно: 1) Прямой доступ к любому элементу по индексу (без прохождения по цепочке связанного однонаправленного списка). 2) Возможность добавления элемента (умный алгоритм выделения памяти, например рост 100% при нехватке места). 3) Возможность удаления, очистки, поиска по ключу. Это то, что в целом требуется от контейнера. Фактически, список - это расширенный динамический массив. Реализовывать списки для каждой структуры данных напряжно и бессмысленно. Всё равно, что каждый раз вручную писать аналоги процедур из стандартной библиотеки. Другой пример. Ассоциативные массивы (хэш-массивы). Модуль в 600 строк должен уметь работать с абстрактным типом данным, иначе какой-то садомазохизм выходит. Если отказываться от абстрактных контейнеров, то нужно приходить к шаблонам и всем проблемам, с ними связанными. |
Автор: | Alexey Veselovsky [ Четверг, 23 Декабрь, 2010 19:31 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Berserker писал(а): От списка нужно: 1) Прямой доступ к любому элементу по индексу (без прохождения по цепочке связанного однонаправленного списка). Это не список |
Автор: | Александр Шостак [ Четверг, 23 Декабрь, 2010 19:56 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
А что же ещё? Порядковый номер элемента - индекс. Многие современные ЯП не разделяют списки от массивов. php, javascript - массивы = списки = стёки (с операциями добавления, удаления, поиска по ключу и при этом прямым доступом). Вопрос лишь в расширении и скорости доступа. В традиционном примитивном списке для доступа к элементу с индексом N нужно пройтись по всем, что до него. Если в основу положить динамический массив, то доступ мгновенный. И такой список универсален и удобен в большинстве случаев. Википедия: Линейный однонаправленный список - то, что вы понимаете под "списком", хотя список не ограничивается такой интерпритацией. "В зависимости от реализации может быть возможен произвольный доступ к элементам списка." - подтверждение моих слов. Линейный однонаправленный список не масштабируем. На тестах было 10 элементов, в реале - 1000. И каждое обращение - в среднем 500 операций доступа. |
Автор: | Info21 [ Четверг, 23 Декабрь, 2010 20:03 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Сергей Прохоренко писал(а): Правильно ли я понимаю, что Oberon-2 с его ООП "как у всех" (т.е. интерфейс-класс-объект) - это тупиковая ветвь эволюции оберонов? Да, да.
|
Автор: | Alexey Veselovsky [ Четверг, 23 Декабрь, 2010 20:20 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Berserker писал(а): Википедия: Линейный однонаправленный список - то, что вы понимаете под "списком", хотя список не ограничивается такой интерпритацией. "В зависимости от реализации может быть возможен произвольный доступ к элементам списка." - подтверждение моих слов. Я бы ЭТО назвал бы линейным контейнером. Berserker писал(а): Линейный однонаправленный список не масштабируем. На тестах было 10 элементов, в реале - 1000. И каждое обращение - в среднем 500 операций доступа. Если регулярно обращаться по индексу, то да А так он вполне масштабируем. Вы просто не умеете его готовить. |
Автор: | Info21 [ Четверг, 23 Декабрь, 2010 20:23 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Berserker писал(а): Линейный однонаправленный список не масштабируем. ... Да-а-а... вот так вот и вылазит страшная подоплёка. |
Автор: | Илья Ермаков [ Четверг, 23 Декабрь, 2010 21:49 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Berserker писал(а): Другой пример. Ассоциативные массивы (хэш-массивы). Модуль в 600 строк должен уметь работать с абстрактным типом данным, иначе какой-то садомазохизм выходит. Если отказываться от абстрактных контейнеров, то нужно приходить к шаблонам и всем проблемам, с ними связанными. А что там делать-то с этими хэш-массивами? Часто делаю. ARRAY N OF Item, где Item - голова связного списка. Далее хэш от ключа - и вперёд линейным поиском среди коллизий в нужном пункте таблице. Ну да, есть категория применений - бизнес-приложения, приложения, сопрягающиеся с интернет-мордами и JavaScript, где мне уже хочется завести какой-то универсальный ассоциативный контейнер, типа как объект в JavaScript. Чтобы хранить иерарахию объектов, доступным по символьным именам. Но это ярко выраженная прикладуха ИС-овского характера. |
Автор: | Александр Ильин [ Пятница, 24 Декабрь, 2010 07:10 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Geniepro писал(а): Александр, да у Вас прямо талант объяснять! Я наконец понял о чём чешут языками в этой теме... :lol: В Обероне такая процедурная переменная должна служить "якорем" связанного объекта для сборщика мусора, т.е. объект не будет удалён из памяти, пока есть процедурные переменные, указывающие на его методы. В Delphi, где удаление объектов ручное, надо следить самостоятельно, а при вызове метода удалённого объекта через процедурную переменную будет то же самое, что при обычном вызове метода удалённого объекта (как правило, будет исключение из-за ошибки доступа к памяти, но не всегда).Конкретно в данном примере возникает вопрос -- на что указывает do, если объект obj2 уничтожен? Или же его нельзя уничтожить, пока где-то висит ссылка на его метод Do? Geniepro писал(а): И ещё, вот конкретно в данном примере можно было бы вполне обойтись таким вариантом: Это сработает только в том случае, если obj1 и obj2 имеют тип SomeObject либо наследуются от SomeObject (иначе не скомпилируется присваивание), и метод Do объявлен в SomeObject, а не в унаследованном типе (иначе не скомпилируется вызов метода). В предлагаемом же варианте с {DELEGATE} объекты могут быть абсолютно независимы иерархически, достаточно только совпадения списка формальных параметров методов, что и проверит компилятор (в примере список пустой). Точно так же, как в обычную процедурную переменную можно присваивать процедуры из несвязанных друг с другом модулей при условии совпадения списка параметров, так и в переменную {DELEGATE} можно присваивать методы любых объектов при условии совпадения списка параметров.
Код: VAR obj: SomeObject; obj := obj1; obj.Do(); (* вызывается obj1.Do *) obj := obj2; obj.Do(); (* вызывается obj2.Do *) |
Автор: | Александр Ильин [ Пятница, 24 Декабрь, 2010 07:32 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
В Delphi главное применение procedure of object - это обработка событий, т.е. объектные callback-и. Есть даже стандартный тип (наиболее часто используемый): TNotifyEvent = procedure (Sender: TObject) of object; Многие объекты VCL публикуют "разъёмы" для подстановки обработчиков событий. Например, если есть объект TButton, то у него наверняка будет событие OnClick: TNotifyEvent; Допустим, мы поместили к себе на окно эту кнопку, и хотим при нажатии на неё что-то посчитать. Окно - это объект типа TMyForm: Код: procedure TMyForm.Create(); Ключевая строчка: btnOK.OnClick := DoOKClick;var btnOK: TButton; begin btnOK := TButton.Create(); // положили кнопку в нужное место, настроили внешний вид btnOK.OnClick := DoOKClick; end; procedure TMyForm.DoOKClick(Sender: TObject); begin // обработка щелчка по кнопке OK // Sender = btnOK, можно привести к типу TButton end; // Кнопка делает вот что procedure TButton.Handle... begin // если назначен обработчик, вызовем его if OnClick <> nil then OnClick(Self); end; По сути, это присваивание процедурной переменной. НО! Эта процедурная переменная должна вызываться для конкретного экземпляра TMyForm, ведь ничто не мешает нам создать три экземпляра объекта типа TMyForm и вести независимые подсчёты в каждом из них. Вот поэтому используется тип procedure of object со скрытой ссылкой на экземпляр объекта TMyForm. На этом механизме построена вся обработка событий в библиотеке Delphi VCL (кроме событий от ОС). |
Автор: | Geniepro [ Пятница, 24 Декабрь, 2010 08:16 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Александр Ильин писал(а): В предлагаемом же варианте с {DELEGATE} объекты могут быть абсолютно независимы иерархически, достаточно только совпадения списка формальных параметров методов, что и проверит компилятор (в примере список пустой). Точно так же, как в обычную процедурную переменную можно присваивать процедуры из несвязанных друг с другом модулей при условии совпадения списка параметров, так и в переменную {DELEGATE} можно присваивать методы любых объектов при условии совпадения списка параметров. Вот это, наверное, не совсем правильно, идеологически, по крайней мере. Для таких целей и нужны более современные системы типов, включающие классы типов или хотя бы интерфейсы в стиле Ява/C#. Если объекты не имеют совершенно ничего общего, то, вероятно, и смысл их методов тоже отличается. Зачем же их перемешивать? Скорее всего это ошибка, ну или легко можно будет допустить ошибку в таких условиях. А если бы была поддержка интерфейсов/классов типов, то такие ошибки отследил бы компилятор. |
Автор: | Galkov [ Пятница, 24 Декабрь, 2010 11:27 ] |
Заголовок сообщения: | Re: Аналог procedure of object в КП |
Вы неправы, все тут правильно. Посмотрите на игрушечный ((с) И.Ермаков) пример. Семантика MediaPlayer.Play и MediaPlayer.Stop - совершенно различна. Не имеющая ничего общего с System.Reboot. Но они прекрасно уживаются в переменной одного типа. Нет тут никаких идеологических неправильностей. Все именно так и задумано. А вот проблемы у CPP-шников - есть: "ай, вот мы сейчас нарисуем шаблоны, а компилятор всю эту прорву (зачем-то) типов соптимизирует в один". Не, не оптимизирует (полностью, по крайней мере, ибо самые продвинутые компиляторы о чем-то начинают таки догадываться) Между прочим, у меня уже несколько таких бесед было... С коллегами, которых на данном форуме принято называть "программист пальцы веером". Мое личное наблюдение: народ понимает таки аргУменты. Сетуют, конечно же, на компилятор: "вот гад, вся же информация у него есть!!!" Но логикой владеют на более высоком уровне, чем поиск нужной фразы в цитатнике |
Страница 8 из 9 | Часовой пояс: UTC + 3 часа |
Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |