Сообщение Re[24]: «Собаку съел» от 26.01.2017 9:38
Изменено 26.01.2017 17:26 vdimas
Re[24]: «Собаку съел»
Здравствуйте, samius, Вы писали:
S>Вот, именно что выглядит "как".
А только это и важно.
Т.е., с одной стороны, у нас есть некий уровень реализации полиморфизма с т.з. программиста:
— перегрузка имен ф-ий;
— виртуальные ф-ии;
— параметрический полиморфизм некоторого ранга (туда же обязательный автовывод типов при ранге большем 1, иначе такой полиморфизм будет неюзабелен).
С другой стороны есть механики его обеспечения компилятором — матчинг типа и соответствующей ему ф-ии/метода на этапе компиляции/оптимизации или на этапе исполнения через таблицу ф-ий, как для случая виртуальных ф-ий в ООП или в некоторых сценариях с использованием классов типов в том же Хаскеле.
S>Класс типов осуществляет диспетчеризацию статически, сводя параметрический и ad hoc полиморфизм в единую модель.
Неверно. Тут в разные годы пробегали примеры на Хаскель с использованием классов типов, где без динамического матчинга времени исполнения никак — компилятор Хаскель создаёт таблицы ф-ий для их инстансов для конкретных типов.
Но все эти вещи, повторюсь, относительно прозрачны для программиста. Начинающего программиста должны интересовать лишь возможности языка, а более опытного — дополнительно понимание "цены" каждого вида полиморфизма в рантайме.
Например, в классике ООП:
— динамический ad hoc полиморфизм на виртуальной ф-ии Draw.
А вот здесь:
хороший компилятор должен должен будет вставить прямой вызов Draw, а не виртуальный, т.е. имеем статический ad hoc полиморфизм.
По-сути мы зацепились вокруг того, что хотя компилятор C# в 99% случаев был бы способен разресолвить параметрический полиморфизм на этапе компиляции (т.е. приведя его к ad hoc через вывод монотипов, прямо как на шаблонах С++), однако же, ради "экономии" размера бинарника всё будет сведено к динамическому ad hoc-полиморфизму на основе виртуальных вызовов типов-ограничений (интерфейсов или абстрактных/виртуальных баз).
S>т.е. если мы ограничиваем рассмотрение типов множеством типов некого класса (или множество типов, с определенным оператором сравнения, конструктором копирования и т.п.), то выходит что это как бы параметрический полиморфизм, несмотря на то, что оно ограничено явным образом.
Разные виды полиморфизма ни в коем случае не ортогональны друг другу, а часто друг через друга выражаются или некие случаи представляют из себя одновременно несколько разновидностей полиморфизма. Поэтому, ИМХО, — это рассуждения вникуда, когда пытаются один вид полиморфизма "тщательно отделить" от другого.
Еще раз. "Полиморфизм" в общем смысле — он ровно один, означает способность ЯП автоматически сопоставлять конкретные одноимённые ф-ии/методы (или операторы, что тоже есть ф-ии) конкретным типам, что позволяет программисту делать меньше работы, т.е. полиморфизм повышает выразительность языка. Но степень подобной "автоматизации" и её рантайм-цена у разных языков разная.
S>Но он параметрический лишь до той степени, пока не потребуется взять тип, не удовлетворяющий ограничению. В то время как кошерно параметрический код не требует от этого типа более ничего.
Ну как это "ничего"? Мы с "самого низа" используем ну хотя бы операторы языка. Операторы — это тоже ф-ии, язык с хорошей поддержкой полиморфизма должен позволять определять семантику этих операторов для различных типов или их классов. Например, в Хаскеле предопределены некоторые базовые классы типов, необходимые для использования операторов языка: Eq, Ord, Num, Real, Integral, Monad или для базовых операций преобразования в строку — Show. Т.е., совсем "из ничего" не получится.
S>Т.е. я могу согласиться с тем, что equal_to параметрически полиморфна на множестве типов с определенным оператором сравнения, объединенном с множеством типов, для которых существует явная специализация equal_to. Но при этом ее ad hoc природу не спрятать.
А вот не надо пытаться тщательно отделять мух от котлет, когда речь о полиморфизме. ))
Потому что это зачастую банально невозможно.
Как конкретный тип может иметь одновременно признаки разных классов, так и конкретный сценарий полиморфизма может одновременно быть случаем совместной работы разных "трюков" обеспечения полиморфизма или даже одновременно являться любым из некоего множества "трюков" в их граничных/частных ситуациях.
S>Вот, именно что выглядит "как".
А только это и важно.
Т.е., с одной стороны, у нас есть некий уровень реализации полиморфизма с т.з. программиста:
— перегрузка имен ф-ий;
— виртуальные ф-ии;
— параметрический полиморфизм некоторого ранга (туда же обязательный автовывод типов при ранге большем 1, иначе такой полиморфизм будет неюзабелен).
С другой стороны есть механики его обеспечения компилятором — матчинг типа и соответствующей ему ф-ии/метода на этапе компиляции/оптимизации или на этапе исполнения через таблицу ф-ий, как для случая виртуальных ф-ий в ООП или в некоторых сценариях с использованием классов типов в том же Хаскеле.
S>Класс типов осуществляет диспетчеризацию статически, сводя параметрический и ad hoc полиморфизм в единую модель.
Неверно. Тут в разные годы пробегали примеры на Хаскель с использованием классов типов, где без динамического матчинга времени исполнения никак — компилятор Хаскель создаёт таблицы ф-ий для их инстансов для конкретных типов.
Но все эти вещи, повторюсь, относительно прозрачны для программиста. Начинающего программиста должны интересовать лишь возможности языка, а более опытного — дополнительно понимание "цены" каждого вида полиморфизма в рантайме.
Например, в классике ООП:
foreach(Vidget v in vidgets)
v.Draw(context);— динамический ad hoc полиморфизм на виртуальной ф-ии Draw.
А вот здесь:
Rectangle r = new Rectangle(bounds);
r.Draw(context);хороший компилятор должен должен будет вставить прямой вызов Draw, а не виртуальный, т.е. имеем статический ad hoc полиморфизм.
По-сути мы зацепились вокруг того, что хотя компилятор C# в 99% случаев был бы способен разресолвить параметрический полиморфизм на этапе компиляции (т.е. приведя его к ad hoc через вывод монотипов, прямо как на шаблонах С++), однако же, ради "экономии" размера бинарника всё будет сведено к динамическому ad hoc-полиморфизму на основе виртуальных вызовов типов-ограничений (интерфейсов или абстрактных/виртуальных баз).
S>т.е. если мы ограничиваем рассмотрение типов множеством типов некого класса (или множество типов, с определенным оператором сравнения, конструктором копирования и т.п.), то выходит что это как бы параметрический полиморфизм, несмотря на то, что оно ограничено явным образом.
Разные виды полиморфизма ни в коем случае не ортогональны друг другу, а часто друг через друга выражаются или некие случаи представляют из себя одновременно несколько разновидностей полиморфизма. Поэтому, ИМХО, — это рассуждения вникуда, когда пытаются один вид полиморфизма "тщательно отделить" от другого.
Еще раз. "Полиморфизм" в общем смысле — он ровно один, означает способность ЯП автоматически сопоставлять конкретные одноимённые ф-ии/методы (или операторы, что тоже есть ф-ии) конкретным типам, что позволяет программисту делать меньше работы, т.е. полиморфизм повышает выразительность языка. Но степень подобной "автоматизации" и её рантайм-цена у разных языков разная.
S>Но он параметрический лишь до той степени, пока не потребуется взять тип, не удовлетворяющий ограничению. В то время как кошерно параметрический код не требует от этого типа более ничего.
Ну как это "ничего"? Мы с "самого низа" используем ну хотя бы операторы языка. Операторы — это тоже ф-ии, язык с хорошей поддержкой полиморфизма должен позволять определять семантику этих операторов для различных типов или их классов. Например, в Хаскеле предопределены некоторые базовые классы типов, необходимые для использования операторов языка: Eq, Ord, Num, Real, Integral, Monad или для базовых операций преобразования в строку — Show. Т.е., совсем "из ничего" не получится.
S>Т.е. я могу согласиться с тем, что equal_to параметрически полиморфна на множестве типов с определенным оператором сравнения, объединенном с множеством типов, для которых существует явная специализация equal_to. Но при этом ее ad hoc природу не спрятать.
А вот не надо пытаться тщательно отделять мух от котлет, когда речь о полиморфизме. ))
Потому что это зачастую банально невозможно.
Как конкретный тип может иметь одновременно признаки разных классов, так и конкретный сценарий полиморфизма может одновременно быть случаем совместной работы разных "трюков" обеспечения полиморфизма или даже одновременно являться любым из некоего множества "трюков" в их граничных/частных ситуациях.
Re[24]: «Собаку съел»
Здравствуйте, samius, Вы писали:
S>Вот, именно что выглядит "как".
А только это и важно.
Т.е., с одной стороны, у нас есть некий уровень реализации полиморфизма с т.з. программиста:
— перегрузка имен ф-ий;
— виртуальные ф-ии;
— параметрический полиморфизм некоторого ранга (туда же обязательный автовывод типов при ранге большем 1, иначе такой полиморфизм будет неюзабелен).
С другой стороны есть механики его обеспечения компилятором — матчинг типа и соответствующей ему ф-ии/метода на этапе компиляции/оптимизации или на этапе исполнения через таблицу ф-ий, как для случая виртуальных ф-ий в ООП или в некоторых сценариях с использованием классов типов в том же Хаскеле.
S>Класс типов осуществляет диспетчеризацию статически, сводя параметрический и ad hoc полиморфизм в единую модель.
Неверно. Тут в разные годы пробегали примеры на Хаскель с использованием классов типов, где без динамического матчинга времени исполнения никак — компилятор Хаскель создаёт таблицы ф-ий для их инстансов для конкретных типов.
Но все эти вещи, повторюсь, относительно прозрачны для программиста. Начинающего программиста должны интересовать лишь возможности языка, а более опытного — дополнительно понимание "цены" каждого вида полиморфизма в рантайме.
Например, в классике ООП:
— динамический ad hoc полиморфизм на виртуальной ф-ии Draw.
А вот здесь:
хороший компилятор должен должен будет вставить прямой вызов Draw, а не виртуальный, т.е. имеем статический ad hoc полиморфизм.
По-сути мы зацепились вокруг того, что хотя компилятор C# в 99% случаев был бы способен разресолвить параметрический полиморфизм на этапе компиляции (т.е. приведя его к ad hoc через вывод монотипов, прямо как на шаблонах С++), однако же, ради "экономии" размера бинарника всё будет сведено к динамическому ad hoc-полиморфизму на основе виртуальных вызовов типов-ограничений (интерфейсов или абстрактных/виртуальных баз).
S>т.е. если мы ограничиваем рассмотрение типов множеством типов некого класса (или множество типов, с определенным оператором сравнения, конструктором копирования и т.п.), то выходит что это как бы параметрический полиморфизм, несмотря на то, что оно ограничено явным образом.
Разные виды полиморфизма ни в коем случае не ортогональны друг другу, а часто друг через друга выражаются или некие случаи представляют из себя одновременно несколько разновидностей полиморфизма. Поэтому, ИМХО, — это рассуждения вникуда, когда пытаются один вид полиморфизма "тщательно отделить" от другого.
Еще раз. "Полиморфизм" в общем смысле — он ровно один, означает способность ЯП автоматически сопоставлять конкретные одноимённые ф-ии/методы (или операторы, что тоже есть ф-ии) конкретным типам, что позволяет программисту делать меньше работы, т.е. полиморфизм повышает выразительность языка. Но степень подобной "автоматизации" и её рантайм-цена у разных языков разная.
S>Но он параметрический лишь до той степени, пока не потребуется взять тип, не удовлетворяющий ограничению. В то время как кошерно параметрический код не требует от этого типа более ничего.
Ну как это "ничего"? Мы с "самого низа" используем ну хотя бы операторы языка. Операторы — это тоже ф-ии, язык с хорошей поддержкой полиморфизма должен позволять определять семантику этих операторов для различных типов или их классов. Например, в Хаскеле предопределены некоторые базовые классы типов, необходимые для использования операторов языка: Eq, Ord, Num, Real, Integral, Monad или для базовых операций преобразования в строку — Show. Т.е., совсем "из ничего" не получится.
S>Т.е. я могу согласиться с тем, что equal_to параметрически полиморфна на множестве типов с определенным оператором сравнения, объединенном с множеством типов, для которых существует явная специализация equal_to. Но при этом ее ad hoc природу не спрятать.
А вот не надо пытаться тщательно отделять мух от котлет, когда речь о полиморфизме. ))
Потому что это зачастую банально невозможно.
Как конкретный тип может иметь одновременно признаки разных классов, так и конкретный сценарий полиморфизма может одновременно быть случаем совместной работы разных "трюков" обеспечения полиморфизма или даже одновременно являться любым из некоего множества "трюков" в их граничных/частных ситуациях.
S>Вот, именно что выглядит "как".
А только это и важно.
Т.е., с одной стороны, у нас есть некий уровень реализации полиморфизма с т.з. программиста:
— перегрузка имен ф-ий;
— виртуальные ф-ии;
— параметрический полиморфизм некоторого ранга (туда же обязательный автовывод типов при ранге большем 1, иначе такой полиморфизм будет неюзабелен).
С другой стороны есть механики его обеспечения компилятором — матчинг типа и соответствующей ему ф-ии/метода на этапе компиляции/оптимизации или на этапе исполнения через таблицу ф-ий, как для случая виртуальных ф-ий в ООП или в некоторых сценариях с использованием классов типов в том же Хаскеле.
S>Класс типов осуществляет диспетчеризацию статически, сводя параметрический и ad hoc полиморфизм в единую модель.
Неверно. Тут в разные годы пробегали примеры на Хаскель с использованием классов типов, где без динамического матчинга времени исполнения никак — компилятор Хаскель создаёт таблицы ф-ий для их инстансов для конкретных типов.
Но все эти вещи, повторюсь, относительно прозрачны для программиста. Начинающего программиста должны интересовать лишь возможности языка, а более опытного — дополнительно понимание "цены" каждого вида полиморфизма в рантайме.
Например, в классике ООП:
foreach(Widget w in widgets)
w.Draw(context);— динамический ad hoc полиморфизм на виртуальной ф-ии Draw.
А вот здесь:
Rectangle r = new Rectangle(bounds);
r.Draw(context);хороший компилятор должен должен будет вставить прямой вызов Draw, а не виртуальный, т.е. имеем статический ad hoc полиморфизм.
По-сути мы зацепились вокруг того, что хотя компилятор C# в 99% случаев был бы способен разресолвить параметрический полиморфизм на этапе компиляции (т.е. приведя его к ad hoc через вывод монотипов, прямо как на шаблонах С++), однако же, ради "экономии" размера бинарника всё будет сведено к динамическому ad hoc-полиморфизму на основе виртуальных вызовов типов-ограничений (интерфейсов или абстрактных/виртуальных баз).
S>т.е. если мы ограничиваем рассмотрение типов множеством типов некого класса (или множество типов, с определенным оператором сравнения, конструктором копирования и т.п.), то выходит что это как бы параметрический полиморфизм, несмотря на то, что оно ограничено явным образом.
Разные виды полиморфизма ни в коем случае не ортогональны друг другу, а часто друг через друга выражаются или некие случаи представляют из себя одновременно несколько разновидностей полиморфизма. Поэтому, ИМХО, — это рассуждения вникуда, когда пытаются один вид полиморфизма "тщательно отделить" от другого.
Еще раз. "Полиморфизм" в общем смысле — он ровно один, означает способность ЯП автоматически сопоставлять конкретные одноимённые ф-ии/методы (или операторы, что тоже есть ф-ии) конкретным типам, что позволяет программисту делать меньше работы, т.е. полиморфизм повышает выразительность языка. Но степень подобной "автоматизации" и её рантайм-цена у разных языков разная.
S>Но он параметрический лишь до той степени, пока не потребуется взять тип, не удовлетворяющий ограничению. В то время как кошерно параметрический код не требует от этого типа более ничего.
Ну как это "ничего"? Мы с "самого низа" используем ну хотя бы операторы языка. Операторы — это тоже ф-ии, язык с хорошей поддержкой полиморфизма должен позволять определять семантику этих операторов для различных типов или их классов. Например, в Хаскеле предопределены некоторые базовые классы типов, необходимые для использования операторов языка: Eq, Ord, Num, Real, Integral, Monad или для базовых операций преобразования в строку — Show. Т.е., совсем "из ничего" не получится.
S>Т.е. я могу согласиться с тем, что equal_to параметрически полиморфна на множестве типов с определенным оператором сравнения, объединенном с множеством типов, для которых существует явная специализация equal_to. Но при этом ее ad hoc природу не спрятать.
А вот не надо пытаться тщательно отделять мух от котлет, когда речь о полиморфизме. ))
Потому что это зачастую банально невозможно.
Как конкретный тип может иметь одновременно признаки разных классов, так и конкретный сценарий полиморфизма может одновременно быть случаем совместной работы разных "трюков" обеспечения полиморфизма или даже одновременно являться любым из некоего множества "трюков" в их граничных/частных ситуациях.