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

Цитата MyNameIsIgor @ 28.11.11, 08:37

С помощью концептов это можно записать так

auto concept Plus<class T>
{
  T operator+ (T, T);
}
 
template<Plus T>
T f(T x, T y)
{
  return x + y;
}

и в случае отсутствия оператора + получить ошибку в духе "T не соответствует концепту Plus". Очень похоже на "T не реализует интерфейс Plus" При этом в данном случае концепт типом данных не является - он может использоваться только как ограничитель на параметр шаблона, эдакий шарповский where на стероидах.
Возникает вопрос: а если соединить описание ограничений на параметр шаблона/дженерика и декларацию интерфейса (т.е. абстрактного типа данных) в одной сущности. И по аналогии с шаблонами/дженериками сделать утиную типизацию таких интерфейсов. Тогда можно написать как-то так

auto concept Plus<class T>
{
  T operator+ (T, T);
}
 
Plus f(Plus x, Plus y)
{
  return x + y;
}

В этом случае функция f может использоваться для любых типов, имеющих оператор +, как и в случае шаблонов.

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

interface Plus {
  Plus add (Plus x);
}

?

Добавлено 28.11.11, 09:23

Цитата D_KEY @ 28.11.11, 08:45

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

тип аргумента не задается через тайпкласс

Добавлено 28.11.11, 09:27

Цитата D_KEY @ 28.11.11, 08:45

У тебя понятие типа зависит от времени связывания и проверок?

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

def f(x, y):
    someSideEffect
    return x + y

someSideEffect выполнится при любых x и y (т.е. независимо от того, правильно ли типизирована программа или нет)

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

Цитата korvin @ 28.11.11, 09:21

угу, и что же будет, если я передам в такую f объекты разных классов, удовлетворяющих Plus?

Будет ровно тоже самое, что и при передачи двух объектов разных классов, удовлетворяющих интерфейсу Plus.

Цитата

тип аргумента не задается через тайпкласс

А это разве не задание типа аргумента через тайпкласс?

somefun :: (Someclass a) => a -> a

DesweR, конечно. Неважен порядок типов в списках для акцепторов:

typedef TList<D3, TList<D2, TList<D1,           TList<Base,  NullType> > > >   Hierarchy;
typedef TList<O3, TList<O2, TList<O1, TList<O4, TList<Other, NullType> > > > > OtherHierarchy;

Это не являлось прям так уж самоцелью, просто так само собой получилось. Порядок же акцепторов в списке, который передаётся диспетчеру, должен соответствовать порядку параметров в мультиметоде:

typedef TList<ConcreteAcceptor, TList<ConcreteAcceptor,      NullType> >                           Acceptors;
typedef TList<ConcreteAcceptor, TList<OtherConcreteAcceptor, TList<ConcreteAcceptor, NullType> > > OtherAcceptors;
 
Dispatcher<TestDispatch2, Acceptors>      disp1;
Dispatcher<TestDispatch3, OtherAcceptors> disp2;
 
struct TestDispatch2
{
  static void apply(Base* b1, Base* b2);
/* ... */
};
 
struct TestDispatch3
{
  static void apply(Base* b1, Other* o, Base* b2);
/* ... */
};

А иначе-то как сигнатуру мультиметода задать однозначно?

Сообщение отредактировано: Qraizer - 28.11.11, 09:35

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

Цитата D_KEY @ 28.11.11, 09:33

А это разве не задание типа аргумента через тайпкласс?

somefun :: (Someclass a) => a -> a

нет. тип все так же любой (a), при чем один и тот же. будь (SomeClass a) указанием типа, это бы означало, что a является субтипом SomeClass

Цитата korvin @ 28.11.11, 09:37

Цитата D_KEY @ 28.11.11, 09:33

А это разве не задание типа аргумента через тайпкласс?

somefun :: (Someclass a) => a -> a

нет. тип все так же любой (a), при чем один и тот же. будь (SomeClass a) указанием типа, это бы означало, что a является субтипом SomeClass

Как это меняет тот факт, что ты определяешь функцию для объектов типа, удовлетворяющего тайпклассу, и что ты делаешь это через тайпкласс?

Цитата D_KEY @ 28.11.11, 09:36

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

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

Добавлено 28.11.11, 09:43

Цитата D_KEY @ 28.11.11, 09:40

Как это меняет тот факт, что ты определяешь функцию для объектов типа, удовлетворяющего тайпклассу, и что ты делаешь это через тайпкласс?

всмысле? это к чему вообще?

Qraizer
т.е. следующее будет верно?

  TSomeClass1 = class
    procedure SomeProc(Foo: TFoo; Bar: TBar);
  end;
 
procedure TSomeClass1.SomeProc(Foo: TFoo; Bar: TBar);
begin
  WriteLn('Foo - Bar');
end;
 
var
  Foo: TFoo;
  Bar: TBar;
begin
  Disp(Foo, Bar);
  Disp(Bar, Foo);
end;

Foo - Bar
Foo - Bar

Цитата D_KEY @ 28.11.11, 09:36

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

мне, кстати интересно посмотреть на какой-нибудь класс, реализующий

auto concept Plus<class T>
{
  T operator+ (T, T);
}

и который может использоваться и в f:

template<Plus T>
T f(T x, T y)
{
  return x + y;
}

, и в g:

Plus g(Plus x, Plus y)
{
  return x + y;
}

Цитата korvin @ 28.11.11, 09:21

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

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

Цитата D_KEY @ 28.11.11, 09:33

Будет ровно тоже самое, что и при передачи двух объектов разных классов, удовлетворяющих интерфейсу Plus.

Т.е. тоже самое, что и для (всевдоджава)

interface Plus {
  Plus add (Plus x);
}
 
class A implements Plus {
  Plus add(Plus x);
}
 
class B implements Plus {
  Plus add(Plus x);
}
 
Plus f(Plus x, Plus y) {
  return x.add(y);
}
 
f(new A(), new B());

Цитата korvin @ 28.11.11, 09:42

не знаю, как там у вас в C++

Причем тут С++?

Цитата

но тайпклассам это не нужно.

Это нужно не им, это нужно программистам, которые ходят динамического связывания наряду со статическим. Ты предлагаешь писать один и тот же, по сути код два раза(для интерфейса и для тайпкласса)?

Цитата

Цитата D_KEY @ 28.11.11, 09:40

Как это меняет тот факт, что ты определяешь функцию для объектов типа, удовлетворяющего тайпклассу, и что ты делаешь это через тайпкласс?

всмысле? это к чему вообще?

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

Добавлено 28.11.11, 10:45

Цитата korvin @ 28.11.11, 10:17

мне, кстати интересно посмотреть на какой-нибудь класс, реализующий

auto concept Plus<class T>
{
  T operator+ (T, T);
}

Соответствующий интерфейс будет иметь такой вид:

interface Plus
{
    Plus operator+(Plus, Plus);
}

Со всеми вытекающими.

Цитата D_KEY @ 28.11.11, 10:42

Ты предлагаешь писать один и тот же, по сути код два раза(для интерфейса и для тайпкласса)?

o_O' зачем?

Цитата D_KEY @ 28.11.11, 10:42

Это к тому, что ты с помощью тайпкласса задаешь тип аргумента(ов) функции.

нет.

Цитата D_KEY @ 28.11.11, 10:42

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

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

Цитата D_KEY @ 28.11.11, 10:42

Соответствующий интерфейс будет иметь такой вид:

interface Plus
{
    Plus operator+(Plus, Plus);
}

Со всеми вытекающими.

Цитата korvin @ 28.11.11, 10:17

мне, кстати интересно посмотреть на какой-нибудь класс, реализующий

auto concept Plus<class T>
{
  T operator+ (T, T);
}

Цитата korvin @ 28.11.11, 11:04

Цитата D_KEY @ 28.11.11, 10:42

Ты предлагаешь писать один и тот же, по сути код два раза(для интерфейса и для тайпкласса)?

o_O' зачем?

Т.е. в языке с тайпклассами интерфейсы не нужны?

Цитата

Цитата D_KEY @ 28.11.11, 10:42

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

нет. я требую любой тип. но требую так же, чтобы для него была определена реализация тайпкласса.

И чем то, что написал ты отличается от того, что написал я?

Цитата

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

Точно так же, как и в случае concept map или паттерна "адаптер"

Цитата

Цитата D_KEY @ 28.11.11, 10:42

Соответствующий интерфейс будет иметь такой вид:

interface Plus
{
    Plus operator+(Plus, Plus);
}

Со всеми вытекающими.

Цитата korvin @ 28.11.11, 10:17

мне, кстати интересно посмотреть на какой-нибудь класс, реализующий

auto concept Plus<class T>
{
  T operator+ (T, T);
}

Предоставь соответствующую реализацию интерфейса - это и будет ответ на твой вопрос.

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

Предоставь соответствующую реализацию интерфейса - это и будет ответ на твой вопрос.

ок... т.е. вместо того, чтобы просто писать

typeclass Plus<A> {
    A add (A);
}
 
type Int {
    int value = 0;
}
 
instance Plus<Int> {
    add (y) {
        return Int(this.value + y.value);
    }
}

необходимо приводить типы к какому-то промежуточному представлению?

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

к какому типу нужно привести "y"? какой фактический тип должен быть у результата "add" разных типов? я уж не говорю о возможной необходимости приведения этого результата к конкретному типу. зачем это все тайпклассам?

Добавлено 28.11.11, 11:38

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

Т.е. в языке с тайпклассами интерфейсы не нужны?

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

Добавлено 28.11.11, 11:42

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

Цитата

Цитата D_KEY @ 28.11.11, 10:42

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

нет. я требую любой тип. но требую так же, чтобы для него была определена реализация тайпкласса.

И чем то, что написал ты отличается от того, что написал я?

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

Цитата korvin @ 28.11.11, 11:33

ок... т.е. вместо того, чтобы просто писать
...
необходимо приводить типы к какому-то промежуточному представлению?
...

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

Цитата

зачем это все тайпклассам?

Тайпклассам это не нужно.

Цитата

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

Т.е. в языке с тайпклассами интерфейсы не нужны?

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

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

Добавлено 28.11.11, 11:48

Цитата korvin @ 28.11.11, 11:33

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

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

Сообщение отредактировано: D_KEY - 28.11.11, 11:48