Re[15]: IEquatable<T>
От: vdimas Россия  
Дата: 15.02.17 05:35
Оценка:
Здравствуйте, samius, Вы писали:

V>>Рефлексия идёт везде, где в либах используется Comparer<T>.Default.

S>Если не нравится рефлексия

Её просто скоро не будет в свободном доступе. ))
Всё ж к этому идёт.


V>>Это отказ от обсуждения систем типов и возможностей параметрического полиморфизма? ))

S>List<T> параметрически полиморфен. Что тут еще обсуждать?

Обсуждалась система типов + курьёзы, связанные с т.н. "типизированным параметрическим полиморфизмом", при попытке использовать его в стиле тру-ООП, когда разработчики такой системы типов решают облегчить себе жизнь.
Не работает это...

В общем, я тут больше отвечал тем, кто считает, что в С++ обитает "неполноценный параметрический полиморфизм".

Там, где ты рядом скипнул, содержалась полная инфа относительно вида параметрического полиморфизма в С++ (он имеет вполне определённую классификацию — т.н. "нетипизированный параметрический полиморфизм"), а так же объяснял, как легко и непринуждённо из нетипизированного сделать типизированный, причем, более полноценный, чем "тру параметрический полиморфизм" в дотнете.


S>Но тебе,видимо уже не нужна работающая функция IndexOf с value-type компарером.


Нужна, но это невозможно для ситуации, если речь идёт об автоматически подставляемом компилятором генерик-компараторе. Тут даже не важно, value-type или ref будет этот компаратор. Соответствующий сниппет я уже приводил. Не компиллируется.


S>Тебе IndexOf вкорячить в List<T>, но не добавить ограничение к типу T.


Это не мне. Это системе типов дотнета.
В Хаскель и С++ запросто сделать отдельные специализации для IEquatable<> и для любых других мыслимых "концептов".


S>Причем, чисто что бы пообсуждать.


Разумеется. Как и всем в этой ветке.
Мы делимся наблюдениями, инфой, сравниваем, понимаем, делаем выводы.


S>А мне достаточно внешней к List<T> функции IndexOf. И та нафиг не нужна на самом деле.


Пофиг на конкретно List<T> — это просто хорошо известный тип, на котором удобно показать, как разработчику придётся решать аналогичные задачи, буде они возникнут, ведь "концептом" удобно задавать любой список допустимых операций согласно прикладного сценария.

Речь сугубо о выразительности библиотек, об отсутствиии необходимости плодить ручную работу (клонирование) — рядом приводил уже ссылки на автогенерённый код, повторить ссылки? В общем, с учётом обсуждения рядом Net Native и ограничений на рефлексию — вопрос не праздный.


V>>Ну вот представь, что рефлексия (т.е. хак системы типов) недоступна.

V>>И сразу станет принципиально.
S>Представил.

Кодогенерацию через T4? ))


S>Ну да, ты ведь полагаешь что как только ты не указал компарер явно и он создался под капотом дядей, то ты обрел параметрический полиморфизм...


Да не горячись ты так, тут вопрос простой как 3 копейки: коль в объявления параметрических типов вводятся ограничения-концепты, то необходимо было сделать концепты частью типа. Вот и всё кино.

Тогда можно было бы использовать т.н. "специализацию" (ad hoc), чтобы иметь возможность автоматически распространять ограничения текущего контекста вычислений для низлежащего вызываемого кода.

Сейчас же в дотнете НЕТ никакой возможности распространить такие ограничения дальше.
И не надо защищать систему типов C# только за то, что это C#. Будь объективен.

Речь идёт вот о такой предполагаемой фишке:
class List<T> : IList<T> 
{...}

class List<T> : IList<T> where T : IEquatable<T> 
{...}

Разные типы. Пример совместной работы ad hoc и параметрического полиморфизма (рядом ты тоже малость путал одно с другим).

Или вот о такой:
class List<T> : IList<T> 
{
    public IndexOf(T value) {}

    public IndexOf(T value) where T : IEquatable<T> {}
}

Разные методы, опять совместная работа разных видов полиморфизма.

В Хаскеле доступен второй вариант, в С++ — оба. И это прекрасно решает озвученную проблематику насчет всяких хаков системы типов/рефлексии.

Обрати внимание, что в дотнете последняя техника особо мощно смотрелась бы в сочетании с техникой методов-расширений. Это была бы просто киллер-фича, натурально.

А то сейчас на код методов-расширений порой без слёз не взглянешь, когда они пытаются через рефлексию отделить массив от List<T> и от IEnumarable<T>. Согласен, порой и такое полезно, когда произошло стирание типа аж до IEnumerable<>, но уж в случае более полных специализаций можно было бы подставлять совсем эффективный код.

Ты как раз рядом спрашивал "зачем сводить к ad hoc?" — дык, сугубо ж для эффективности! ))


S>Ждем конкурирующие классификации.


Они уже есть от авторов Хаскеля. В Хаскеле работает т.н. "предикативный/пренексный полиморфизм", совместно с той фишкой, что ограничения на полиморфный аргумент являются частью типа (ес-но!) этого аргумента.

В дотнете ограничения на тип НЕ являются частью типа. Ну вот попытайся ты хаскелистам объяснить, как так у вас вышло, что параметрические аргументы методов или типов навроде `Eq a` и `Num a` с т.з. системы типов неразличимы.
Услышишь много интересного.

В общем, это был ответ тем, кто утверждает, что в C# наблюдается "настоящий типизированный параметрический полиморфизм", а вот в С++ — "ненастоящий". Вот НС любит периодически такое задвигать. ))
Эти люди просто не понимают о чем речь.

=========
Сорри, что целиком озвучил самую первую исходную мысль прямо сейчас именно тебе — не прими лично.
Просто нашел собеседника, которому можно подобное озвучивать и он достоверно поймёт, о чем речь. ))
Считай, блажь такая, чтобы не вещать совсем уж в Космос. ))
Отредактировано 15.02.2017 5:37 vdimas . Предыдущая версия .
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.