Delphi vs C++ vs C# , ну и Java немножко, где-то ближе к старшему байту номеров страниц

Цитата D_KEY @ 28.11.11, 11:44

Но ты в них задаешь одно и тоже - контракт, причем задаешь одни и тем же образом.

По-моему, просто синтаксис концептов не позволяет удобно описать и параметр шаблона, и интерфейс, согласись. Для этого нужно что-то другое

Цитата MyNameIsIgor @ 28.11.11, 11:48

По-моему, просто синтаксис концептов не позволяет удобно описать и параметр шаблона, и интерфейс, согласись

Соглашусь Я и не утверждал, что подходит...

Цитата D_KEY @ 28.11.11, 11:44

Почему вместо? Почему необходимо?

потому что мы не можем просто использовать первый код, там мы работаем с конкретным типом, с его внутренним представлением, без посредников.
во втором случае мы работаем просто с интерфейсом Plus, о его внутренней структуре мы ничего не знаем, следовательно должны приводить его к какому-то промежуточному значению. т.е. в первом случае мы складываем, например, рубли с рублями, а во втором -- рубли с некоторой валютой, которую приводим к какой-то универсальной валюте. тот код даже нужно подправить так:

interface Plus {
    Plus add(Plus);
    Intermediate toIntermediate();
}
 
class Int implements Plus {
    int value = 0;
    
    public Int() {}
    public Int(Intermediate x) {
        ...
    }
    
    public Plus add(Plus y) {
        return Int(this.toIntermediate + y.toIntermediate);
    }
}

в итоге, мы придем к тому, что интерфейсы вообще окажутся ненужными и мы вполне можем обойтись тайпклассами.

korvin, давайте я попробую переписать код так

// Концепт/интерфейс, параметризируется неким типом
concept Plus<class T>
{
  T operator+ (T, T);
}
 
// Шаблонная функция
template<class T>
requares Plus<T>    // Требуем, чтобы для типа T выполнялся концепт Plus, т.е. существовал operator+ (T, T)
T f(T x, T y)
{
  return x + y;
}
 
Plus<int> f(Plus<int> x, Plus<int> y)   // Здесь уже Plus - это интерфейс, а int - то самое промежуточное представление
{
  return x + y;
}

Ещё раз хочется отметить: на мой взгляд, здесь дело в синтаксисе, он вносит путаницу, а не в идее. Я просто неудачно выбрал концепты для её иллюстрации, ничего более подходящего в голову не лезет.

Цитата korvin @ 28.11.11, 12:05

т.е. в первом случае мы складываем, например, рубли с рублями, а во втором -- рубли с некоторой валютой, которую приводим к какой-то универсальной валюте.

А чем тебя не устроит кинутое исключение в операторе + конкретного типа при обнаружении, что аргумент метода имеет какой-то другой тип? Так ведут себя все динамические языки.

Цитата

в итоге, мы придем к тому, что интерфейсы вообще окажутся ненужными и мы вполне можем обойтись тайпклассами.

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

Цитата D_KEY @ 28.11.11, 12:16

А чем тебя не устроит кинутое исключение в операторе + конкретного типа при обнаружении, что аргумент метода имеет какой-то другой тип?

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

Цитата MyNameIsIgor @ 28.11.11, 12:28

Цитата D_KEY @ 28.11.11, 12:16

А чем тебя не устроит кинутое исключение в операторе + конкретного типа при обнаружении, что аргумент метода имеет какой-то другой тип?

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

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

Цитата D_KEY @ 28.11.11, 11:44

Нет, только тот, для которого есть инстанс. Если инстанса нет, то аргумент не пройдет

о чем нам сообщит компилятор, и мы определим инстанс для любого типа, любого класса типов.

Цитата D_KEY @ 28.11.11, 11:44

точно также, как в случае утиных интерфейсов, если наш тип не удовлетворяет интерфейсу и/или не создан соответствующий адаптер.

только статическая информация о типе стирается, ага

Добавлено 28.11.11, 12:40

Цитата MyNameIsIgor @ 28.11.11, 12:13

korvin, давайте я попробую переписать код так

давай ты просто напишешь реализацию класса

Цитата korvin @ 28.11.11, 12:38

о чем нам сообщит компилятор, и мы определим инстанс для любого типа, любого класса типов.

В случае интерфейсов нам так же сообщит компилятор, а о чем не сможет - сообщит рантайм система языка.

Цитата

Цитата D_KEY @ 28.11.11, 11:44

точно также, как в случае утиных интерфейсов, если наш тип не удовлетворяет интерфейсу и/или не создан соответствующий адаптер.

только статическая информация о типе стирается, ага

Так никто же не говорит о замене

Цитата D_KEY @ 28.11.11, 12:16

А чем тебя не устроит кинутое исключение в операторе + конкретного типа при обнаружении, что аргумент метода имеет какой-то другой тип? Так ведут себя все динамические языки.

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

Цитата D_KEY @ 28.11.11, 12:16

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

в статически-типизированном языке с тайпклассами, параметрическим полиморфизмом и выводом типов? нет, не захочется.

Добавлено 28.11.11, 12:49

Цитата D_KEY @ 28.11.11, 12:41

В случае интерфейсов нам так же сообщит компилятор, а о чем не сможет - сообщит рантайм система языка.

ага, это весьма круто, ловить ошибки типизации в рантайме программы, написанной на статически-типизированном языке.

Цитата korvin @ 28.11.11, 12:46

в статически-типизированном языке с тайпклассами, параметрическим полиморфизмом и выводом типов? нет, не захочется.

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

Добавлено 28.11.11, 12:51

Цитата korvin @ 28.11.11, 12:46

Цитата D_KEY @ 28.11.11, 12:41

В случае интерфейсов нам так же сообщит компилятор, а о чем не сможет - сообщит рантайм система языка.

ага, это весьма круто, ловить ошибки типизации в рантайме программы, написанной на статически-типизированном языке.

Если тебе не нужно это в динамике, делай все в статике, в чем проблема? Разве это повод запрещать такие механизмы?

Цитата D_KEY @ 28.11.11, 12:49

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

в хаскелле нет рантайма =) но ты можешь предложить конкретный пример своей волшебной ситуации и мы посмотрим, что тут может предложить хаскелл, мне пока таких ситуаций на ум не приходит =/

Добавлено 28.11.11, 13:01

Цитата D_KEY @ 28.11.11, 12:49

Если тебе не нужно это в динамике, делай все в статике, в чем проблема? Разве это повод запрещать такие механизмы?

запрещать механизм, приводящий к потере информации о типе в статике?... да, это не повод, это причина

Добавлено 28.11.11, 13:04
только не надо примеров вида "необходимо в зависимости от входных данных, вернуть объекты разных типов" =) это не задача, а способ решения =)

Сообщение отредактировано: korvin - 28.11.11, 13:04

Цитата korvin @ 28.11.11, 12:58

только не надо примеров вида "необходимо в зависимости от входных данных, вернуть объекты разных типов" =) это не задача, а способ решения =)

Хм. Если это способ решения, то какой задачи? И что тут предлагает Haskell?

Цитата D_KEY @ 28.11.11, 13:06

Хм. Если это способ решения, то какой задачи? И что тут предлагает Haskell?

вот ты мне и скажи

Можешь для начала рассказать, как делается в Haskell сериализация и восстановление. А там посмотрим.