Здравствуйте, Eye of Hell, Вы писали:

Кстати, если оперировать вот этим
http://en.wikipedia.org/wiki/Polymorphism_%28computer_science

There are several fundamentally different kinds of polymorphism

то получается нельзя путать разные варианты полиморфизма между собой. Т.е. нельзя говорить, что Ad-hoc polymorphism является упрощенным вариантом Subtype polymorphism. Это математически некорректно, как и упоминание полиморфизма вообще без конкретизации по его контексту
Есть разные полиморфизмы. А программист мысля разные объекты единообразно должен еще сообразить как запихнуть свое единообразное мышление в программу с помощью того, этого или другого полиморфизма. Или ну его вообще этот полиморфизм который так галимо отражает наше естественное мышление

Кстати полиморфные типы википедии известны. Правда не вы о них спрашивали, но вам отвечать приятнее

V>Ладно уламали. Но в СОМ есть наследование интерфейсов, нету наследования реализаций.

В целом рад, что мои теоретические знания достаточны, чтобы аргументированно доказать свою позицию .

V>Почему тогда вы сами признались что перегрузка и полиморфизм должны быть разными вещами? Не потому ли что такие общие понятия как полиморфизм во всех своих проявлениях не имеют для программиста практической пользы? Программисту нужно знать какой именно полиморфизм используется в каждом конкретном случае. Это же кошмар просто чтобы компилятор сам решал какой именно вариант полиморфизма должен использоваться Ad-hoc, Parametric или Subtype polymorphism. Вот даже разные названия придумали для специфических частных случаев. Значит нельзя говорить о пользе полиморфизма в программировании вообще в самом общем смысле. Каждая разновидность полиморфизма полезна по своему применяется в разных случаях, должна явно разграничиваться синтаксически и иметь свои достоинства и недостатки. А это подводит нас к вопросу охватывают ли все известные варианты полиморфизма полностью то, что сам программист называет "мыслить разные объекты единообразно"?

На мой профессиональный взгляд, понимание общих понятий позволяет лучше определить что, как и когда применять. Понимание того, что полиморфизм — это когда один и тот же код работает над разными данными — позволяет программисту чуть лучше писать программы. Я считаю, что чем лучше программист понимает почему и зачем в языках программирования и платформах какие-то фичи реализованые каким-то способом — тем лучше у него получаются программы. Да, для клепания формочек не обязательно знать чем "expression" отличается от "statement" и что такое "expression statement". Для практического применения достаточно знаний вида "эта хренька вот в эу хреновину, и — хоп!". Но мы ведь стремимся к лучшему?

V>то получается нельзя путать разные варианты полиморфизма между собой. Т.е. нельзя говорить, что Ad-hoc polymorphism является упрощенным вариантом Subtype polymorphism. Это математически некорректно, как и упоминание полиморфизма вообще без конкретизации по его контексту

Полиморфизм вообще — это возможность выполнять одну и ту же операцию над разными данными. Достаточно высокоуровневое определение, которое позволяет ответить на вопрос "когда и зачем применять эту штуку". А конкретных реализаций очень много.

V>Есть разные полиморфизмы. А программист мысля разные объекты единообразно должен еще сообразить как запихнуть свое единообразное мышление в программу с помощью того, этого или другого полиморфизма. Или ну его вообще этот полиморфизм который так галимо отражает наше естественное мышление

Программирование само по себе — это перевод с человеческого языка на компьютерный. Как только мы сможем общаться с компьютером без переводчика — программирование исчезнет как класс.

V>Кстати полиморфные типы википедии известны. Правда не вы о них спрашивали, но вам отвечать приятнее

Спасибо за комплимент .

Здравствуйте, Eye of Hell, Вы писали:

V>>то получается нельзя путать разные варианты полиморфизма между собой. Т.е. нельзя говорить, что Ad-hoc polymorphism является упрощенным вариантом Subtype polymorphism. Это математически некорректно, как и упоминание полиморфизма вообще без конкретизации по его контексту
EOH>Полиморфизм вообще — это возможность выполнять одну и ту же операцию над разными данными. Достаточно высокоуровневое определение, которое позволяет ответить на вопрос "когда и зачем применять эту штуку". А конкретных реализаций очень много.

Наверно всетаки если бы параметризация была разновидностью Subtype polymorphism то это так бы и описали, но у математиков есть привычка называть объекты принципиально разными если их определения практически не отличаются друг от друга. Вы же не скажите, что Ad-hoc polymorphism во всех самых сложных ситуациях является не более чем Subtype polymorphism в каждом простом случае. Если бы это было так. то механизмы поддерживающие эти концепции в языках программирования были бы одними и теми же, а это не так. Нельзя забывать, например, что объединение разных концепций под одним названием "Полиморфизм" не является таким простым действием как нам бы того хотелось. Напомню историю с классификацией простых конечных групп :

чего там такого — это просто простые конечные группы :)

В 1970-е годы более сотни специалистов по теории групп образовали своеобразный консорциум, целью которого было представить полную классификацию простых конечных групп.
...
Но даже если проект увенчается исчерпывающим итоговым докладом, в мире, наверное, не найдется и десяти математиков, которые будут вправе утверждать, что они понимают хотя бы основные линии многотомного доказательства.

V>>Есть разные полиморфизмы. А программист мысля разные объекты единообразно должен еще сообразить как запихнуть свое единообразное мышление в программу с помощью того, этого или другого полиморфизма. Или ну его вообще этот полиморфизм который так галимо отражает наше естественное мышление
EOH>Программирование само по себе — это перевод с человеческого языка на компьютерный. Как только мы сможем общаться с компьютером без переводчика — программирование исчезнет как класс.

Я усиленно предлагал вам иную точку зрения, когда программирование является рассуждением программиста о программе, а описание программы на естественном языке не более чем состояние этого процесса в определенный момент времени. То есть в разные моменты времени описания различны и различие принципиальное и не устранимое. Потому умение переводить с с естественного языка не заменяет, собственно, программирования .

Хочу сказать что программисту важнее знание механизмов чем математическое обоснование, когда программист думает про Ad-hoc polymorphism он учитывает правила преобразования типов и ограничения связанные с этим, когда программист думает про Subtype polymorphism он учитывает иерархию типов, ведь не любые два классы должны удовлетворять требованиям полиморфизма, когда программист думает про Parametric polymorphism то он должен помнить про нюансы value и reference типов. Значит опыт должен научить программиста воспринимать перегрузку и полиморфизм классов как совершенно разные задачи сопровождающиеся очень разными размышлениями. Даже в том случае если с математической точки зрения это все подвиды одного и того же математичексого понятия.

Не стоит забывать что довольно долгое время программисты и ученые верили в невозможность того, что компьютер может допустить ошибку — там же математическое обеспечение, а в математике нет и не может быть ошибок. Разве что случится катаклизм и логический элемент выдаст 2+2=5 ! Теперь же математическое обеспечение переименовали в программное обеспечение и не возражают против присутствие хотябы одной ошибки в любой программе . Несмотря на то что компиляторы основаны на сложных математический теориях они реализуют лишь конкретный частный случай этих теорий. Потому не стоит упрощать полиморфизм в программировании до полиморфизма в строгом математическом смысле. Это чревато заблуждениями и явными теоретическими ошибками.

И опыт будет говорить программисту со стажем, что это совершенно разные вещи несмотря на одинаковость математического определения. Как и получалось у вас А теоретическая подготовка будет говорить обратное — хоть убейся но нет принципиального отличия в определениях. Так же как и у вас но в другом посте

V> Или ну его вообще этот полиморфизм который так галимо отражает наше естественное мышление

а может ну его вообще это галимое программирование, а?

Здравствуйте, m e, Вы писали:

V>> Или ну его вообще этот полиморфизм который так галимо отражает наше естественное мышление
ME>а может ну его вообще это галимое программирование, а?

А подумать?

V>А подумать?

кому и над чем подумать? если тебе подумать над полиморфизмом -- то это хорошая мысль

Здравствуйте, Vaako, Вы писали:

V>Здравствуйте, Eye of Hell, Вы писали:

V>Наверно всетаки если бы параметризация была разновидностью Subtype polymorphism то это так бы и описали, но у математиков есть привычка называть объекты принципиально разными если их определения практически не отличаются друг от друга. Вы же не скажите, что Ad-hoc polymorphism во всех самых сложных ситуациях является не более чем Subtype polymorphism в каждом простом случае.
Я вообще не понял, откуда взялось предложение считать Ad-hoc разновидностью Subtype-а. Вроде как это твои фантазии.
Странно, что ты это обсуждаешь сам с собой, цитируя при этом Eye of Hell-а.

V>Если бы это было так. то механизмы поддерживающие эти концепции в языках программирования были бы одними и теми же, а это не так.
Это не так. Да и с чего быть одинаковыми механизмам, если один вид полиморфизма выполняется во время компиляции, а другой во время выполнения?

V>Наверно всетаки если бы параметризация была разновидностью Subtype polymorphism то это так бы и описали, но у математиков есть привычка называть объекты принципиально разными если их определения практически не отличаются друг от друга. Вы же не скажите, что Ad-hoc polymorphism во всех самых сложных ситуациях является не более чем Subtype polymorphism в каждом простом случае. Если бы это было так. то механизмы поддерживающие эти концепции в языках программирования были бы одними и теми же, а это не так. Нельзя забывать, например, что объединение разных концепций под одним названием "Полиморфизм" не является таким простым действием как нам бы того хотелось. Напомню историю с классификацией простых конечных групп.

Увы, программирование — достаточно молодая область, и хорошей, выверенной веками классификации у нас пока нема. Работаем с тем что есть (c).

V>Хочу сказать что программисту важнее знание механизмов чем математическое обоснование, когда программист думает про Ad-hoc polymorphism он учитывает правила преобразования типов и ограничения связанные с этим, когда программист думает про Subtype polymorphism он учитывает иерархию типов, ведь не любые два классы должны удовлетворять требованиям полиморфизма, когда программист думает про Parametric polymorphism то он должен помнить про нюансы value и reference типов. Значит опыт должен научить программиста воспринимать перегрузку и полиморфизм классов как совершенно разные задачи сопровождающиеся очень разными размышлениями. Даже в том случае если с математической точки зрения это все подвиды одного и того же математичексого понятия.

Мне кажется, что вы упускаете один важный нюанс. Программист не сразу идет бороть наследование в C++. Вначале у него стоит задача — есть какой-то код и есть разные объекты, один код должен оперировать этими объектами. Зная, что это задача для полиморфизма и что этого полиморфизма есть много разного, программист пырится на ассортимент и выбирает что ему лучше использовать в данном конкретном случае: перегрузку метода, или общий интерфейс для объектов сделать, или наследовать их от общего предка, или реализовать алгорим шаблоном. На мой взгляд, именно это понимаение "нафига полиморфизм нужен вообще" позволяет адекватно выбрать способ решения текущей задачи.

V>И опыт будет говорить программисту со стажем, что это совершенно разные вещи несмотря на одинаковость математического определения. Как и получалось у вас А теоретическая подготовка будет говорить обратное — хоть убейся но нет принципиального отличия в определениях. Так же как и у вас но в другом посте

Баланс между чистой теорией определений и практикой реализаций тех или иных костылей в конкретных языках программирования — наше усе. Я за баланс — чтобы и теория была — общее так сказать понимание, и практика — где какие таблицы виртуальных функций используются и как виртуальная машина пеготает.

1. Ad-hoc полиморфизм и subtype-полиморфизм являются частным случаем Parametric полиморфизма.

это можно показать следующим образом: допустим, что мы можем выполнять произвольные алгоритмы над кодом во время компиляции (в C++ это, в частности, возможно, но правда не ко всем данным уровня компиляции при этом есть доступ), тогда при параметрическом полиморфизме возможен следующий код (где compile-if это условие которое проверяется на уровне компиляции):

//parametric polymorphism
TItem[] Concat<TCollection, T>(T[] items1, TCollection items2) where TCollection:IEnumerable<T>
{
  var result = new List<T>();
  compile-if (TCollection is ICollection<T>)
  {
     result.Capacity = items1.Length + items2.Count;
  }
  else
  {
    result.Capacity = items1.Length;
  }
  result.AddRange(items1);
  compile-if (TCollection is Array<T>)
  {
    result.AddRange(items2);
  }
  else
  {
    foreach (var item in items2)
      result.Add(item);
  }
  return result.ToArray();
}

применив теорию категорий, видим, что этот код дает три варианта перегруженной реализации функции Concat

//ad-hoc polymorphism
T[] Concat<T>(T[] items1, T[] items2)
{
  var result = new List<T>();
  result.Capacity = items1.Length + items2.Count;

  result.AddRange(items1);
  result.AddRange(items2);

  return result.ToArray();
}
T[] Concat<T>(T[] items1, ICollection<T> items2)
{
  var result = new List<T>();
  result.Capacity = items1.Length + items2.Count;

  result.AddRange(items1);

  foreach (var item in items2)
    result.Add(item);

  return result.ToArray();
}
T[] Concat<T>(T[] items1, IEnumerable<T> items2)
{
  var result = new List<TItem>();

  result.AddRange(items1);

  foreach (var item in items2)
      result.Add(item);

  return result;
}

2. Subtype полиморфизм является частным случаем параметрического полиморфизма, если компилятору разрешено самостоятельно добавлять методы в виртуальную таблицу типов.
и subtype-полиморфизм появляется, если тип конкретных данных известен не полностью на этапе компиляции.

это можно увидеть на следующим примере:
введем вспомогательные функции

int[] F1()
{
  return new[]{1, 4, 5};
}
IEnumerable<int> F2()
{
  for (int i = 0; i < 5; ++i)
   yield return i;
}

в следующем коде вся информация известна на уровне компиляции о реальном типе коллекции, которые хранятся в f1 и f2, и поэтому можно выбрать нужный вариант Concat на уровне компиляции

var s = new int[]{4, 6, 7};
var f1 = F1();
var f2 = F2();

var x1 = Concat(s, f1);//здесь выбирается функция для Array
var x2 = Concat(s, f2);//здесь для IEnumerable

но в следующем коде, реальный тип коллекции, хранящейся в f — уже неопределен на уровне компиляции, и окончательно становится определенным только в рантайме:

var f = new Random().Next() > 0.5 ? F1() : F2();
var x = Concat(s, f);

и есть три варианта:
1. подставить общий худший вариант (в данном случае — Concat для IEnumerable), но это не обеспечивает максимальной производительности
2. сгенерить Concat с проверками уровня рантайма, это лучше, но появляются затраты на проверку if-а

T[] Concat_Enumerable_Or_Array<T>(T[] items1, IEnumerable<T> items2)
{
  if (items2 is T[])
    return Concat(items1, (T[])items2);
  return Concat(items1, items2);
}

и вставить вызов этой функции

var x = Concat_Enumerable_Or_Array(s, f);

3. добавить виртуальный метод V_Concat(T[] items1) в таблицу всех классов наследованных от IEnumerable<T>
тогда в массив добавится метод

T[] V_Concat(T[] items)
{
  return Concat(items, (T[])this);
}

во все классы отнаследованных от ICollection<T> добавится метод

//subtype полиморфизм
T[] V_Concat(T[] items)
{
  return Concat(items, (ICollection<T>)this);
}

и в оставшиеся классы отнаследованные от IEnumerable<T> добавится

T[] V_Concat(T[] items)
{
  return Concat(items, (IEnumerable<T>)this);
}

и вызов для расчета x заменяется на

return x = f.V_Concat(s);

зы
V> Это же кошмар просто чтобы компилятор сам решал какой именно вариант полиморфизма должен использоваться Ad-hoc, Parametric или Subtype polymorphism.

компилятору как раз просто выбрать подходящий вариант, и я надеюсь показал каким способом.
а вот для человека удержать в голове все эти нюансы — вот это действительно кошмар.

Здравствуйте, DarkGray, Вы писали:

DG>1. Ad-hoc полиморфизм и subtype-полиморфизм являются частным случаем Parametric полиморфизма.
Если заглянуть в определения, то выяснится что параметрический и ad-hoc полиморфизмы противостоят друг другу в том как используется код для разных типов. Параметрический использует в точности один и тот же код, а ad-hoc различный для разных типов. Потому ad-hoc не может быть частным случаем параметрического.

DG>это можно показать следующим образом: допустим, что мы можем выполнять произвольные алгоритмы над кодом во время компиляции (в C++ это, в частности, возможно, но правда не ко всем данным уровня компиляции при этом есть доступ), тогда при параметрическом полиморфизме возможен следующий код (где compile-if это условие которое проверяется на уровне компиляции):
Если ты применить разные алгоритмы к коду во время компиляции, то ты получишь разный код для разных случаев. А значит — ad-hoc.

DG>

DG>//parametric polymorphism
DG>TItem[] Concat<TCollection, T>(T[] items1, TCollection items2) where TCollection:IEnumerable<T>
DG>{
DG>  var result = new List<T>();
DG>  compile-if (TCollection is ICollection<T>)
DG>

твой compile-if — это фактически как специализация шаблона в C++ (if (is_collection<TCollection>()) с последующим выкидыванием компилятора веток if-а. Т.е. пример нельзя отнести к чистому параметрическому полиморфизму.

DG>применив теорию категорий, видим, что этот код дает три варианта перегруженной реализации функции Concat
Можно развернуть для тех кто в танке причем тут теория категорий?

DG>2. Subtype полиморфизм является частным случаем параметрического полиморфизма, если компилятору разрешено самостоятельно добавлять методы в виртуальную таблицу типов.
Subtype полиморфизм имеет отношение к параметрическому уже потому что типы заменимы подтипами (это безотносительно принципа LSP, т.е. никакого переопределения поведения здесь еще нет).
Однако, в рамках OOP языков говоря о subtype подразумевают возможность переопределения методов для подтипов. А это есть ничто иное, как специализация, или ad-hoc, с той лишь разницей, что работает в рантайме.

DG>>1. Ad-hoc полиморфизм и subtype-полиморфизм являются частным случаем Parametric полиморфизма.
S>Если заглянуть в определения, то выяснится что параметрический и ad-hoc полиморфизмы противостоят друг другу в том как используется код для разных типов. Параметрический использует в точности один и тот же код, а ad-hoc различный для разных типов. Потому ad-hoc не может быть частным случаем параметрического.

ты опять хочешь поделить мир только на черное и белое.

List<T> использует параметрический или ad-hoc полиморфизм?
для List<Control> и List<File> используется один и тот же код, а вот для List<int> уже второй, а для List<double> третий.

такое явление как использование одного кода или разного для исполнения есть, но к делению на parametric/ad-hoc polymorphism он никакого отношения не имеет.

DG>>применив теорию категорий, видим, что этот код дает три варианта перегруженной реализации функции Concat
S>Можно развернуть для тех кто в танке причем тут теория категорий?

разбиение множества на непересекающие множества в зависимости от отношений между элементами — как раз теория категорий и занимается.

Здравствуйте, DarkGray, Вы писали:


DG>>>1. Ad-hoc полиморфизм и subtype-полиморфизм являются частным случаем Parametric полиморфизма.
S>>Если заглянуть в определения, то выяснится что параметрический и ad-hoc полиморфизмы противостоят друг другу в том как используется код для разных типов. Параметрический использует в точности один и тот же код, а ad-hoc различный для разных типов. Потому ad-hoc не может быть частным случаем параметрического.

DG>ты опять хочешь поделить мир только на черное и белое.
Это ты хочешь всех запутать.

DG>List<T> использует параметрический или ad-hoc полиморфизм?
Параметрический.
DG>для List<Control> и List<File> используется один и тот же код, а вот для List<int> уже второй, а для List<double> третий.
Один код. Как и для std::vector, который тоже является образцом параметрического полиморфизма.

DG>такое явление как использование одного кода или разного для исполнения есть, но к делению на parametric/ad-hoc polymorphism он никакого отношения не имеет.
Конечно же имеет.

http://en.wikipedia.org/wiki/Parametric_polymorphism

Using parametric polymorphism, a function or a data type can be written generically so that it can handle values identically without depending on their type. Such functions and data types are called generic functions and generic datatypes respectively and form the basis of generic programming.

Сходи так же по ссылке на generic programming, увидишь там List<T>.

http://en.wikipedia.org/wiki/Ad-hoc_polymorphism

ad-hoc polymorphism is a kind of polymorphism in which polymorphic functions can be applied to arguments of different types, because a polymorphic function can denote a number of distinct and potentially heterogeneous implementations depending on the type of argument(s) to which it is applied.
...
This is in contrast to parametric polymorphism, in which polymorphic functions are written without mention of any specific type, and can thus apply a single abstract implementation to any number of types in a transparent way. This classification was introduced by Christopher Strachey in 1967.

Обрати так же внимание, что эта классификация была введена в 67-м году и не нуждается в переизобретении 55 лет спустя.

Здравствуйте, DarkGray, Вы писали:


DG>>>применив теорию категорий, видим, что этот код дает три варианта перегруженной реализации функции Concat
S>>Можно развернуть для тех кто в танке причем тут теория категорий?

DG>разбиение множества на непересекающие множества в зависимости от отношений между элементами — как раз теория категорий и занимается.
Меня интересует, как именно ты применил теорию категорий, что конкретно из нее. Я просто подозреваю что ты применил не теорию категорий, а умное сочетание слов.

DG>>List<T> использует параметрический или ad-hoc полиморфизм?
S>Параметрический.
DG>>для List<Control> и List<File> используется один и тот же код, а вот для List<int> уже второй, а для List<double> третий.
S>Один код.

ошибаешься

The interesting question is how does .NET compile the generic IL of the server to machine code. It turns out that the actual machine code produced depends on whether the specified types are value or reference type. If the client specifies a value type, then the JIT compiler replaces the generic type parameters in the IL with the specific value type, and compiles it to native code. However, the JIT compiler keeps track of type-specific server code it already generated. If the JIT compiler is asked to compile the generic server with a value type it has already compiled to machine code, it simply returns a reference to that server code. Because the JIT compiler uses the same value-type-specific server code in all further encounters, there is no code bloating.

If the client specifies a reference type, then the JIT compiler replaces the generic parameters in the server IL with Object, and compiles it into native code. That code will be used in any further request for a reference type instead of a generic type parameter. Note that this way the JIT compiler only reuses actual code. Instances are still allocated according to their size off the managed heap, and there is no casting.

http://msdn.microsoft.com/en-us/library/ms379564(v=vs.80).aspx

S> Как и для std::vector, который тоже является образцом параметрического полиморфизма.

здесь тем более. C++ под каждый новый параметр шаблона генерит новый код.

S>Меня интересует, как именно ты применил теорию категорий, что конкретно из нее. Я просто подозреваю что ты применил не теорию категорий, а умное сочетание слов.

есть множество типов они связаны стрелкой is.
дальше есть стрелки:
IEnumerable<T> -> A
!IEnumerable<T> -> ()
ICollection<T> -> B
!ICollection<T> -> ()
Array<T> -> C1
!Array<T> -> C2
при этом A, B, C1, C2 независимые между собой элементы.
вопрос: насколько комбинаций A, B, C1, C2 множество типов разбивается, и какие они?

S>Сходи так же по ссылке на generic programming, увидишь там List<T>.

кроме знания теории необходимо ее еще уметь применять к практике.

в теории List<T> и std::vector<T> может быть и имеют один код, но в жестокой практике: List<T> в .net-е генерит разный код, а уж std::vector в C++ тем более.

Здравствуйте, DarkGray, Вы писали:

DG>The interesting question is how does .NET compile the generic IL of the server to machine code. It turns out that the actual machine code produced depends on whether the specified types are value or reference type.

DG>здесь тем более. C++ под каждый новый параметр шаблона генерит новый код.

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

Здравствуйте, DarkGray, Вы писали:


DG>>>List<T> использует параметрический или ad-hoc полиморфизм?
S>>Параметрический.
DG>>>для List<Control> и List<File> используется один и тот же код, а вот для List<int> уже второй, а для List<double> третий.
S>>Один код.

DG>ошибаешься

DG>

DG>It turns out that the actual machine code produced depends on whether the specified types are value or reference type.

Т.е. ты решил соскочить с темы полиморфизма в языка программирования на полиморфизм инструкций исполнителя?

S>> Как и для std::vector, который тоже является образцом параметрического полиморфизма.

DG>здесь тем более. C++ под каждый новый параметр шаблона генерит новый код.
Генерит — да. Но контейнер написан без учета специальных знаний о типах. А значит параметрический.
Определение полиморфизма ведь не запрещает генерить разный код. Определение полиморфизма касается черт языка, а не черт генератора.