trait + impl vs class , навеяно Rust'ом

Цитата Serafim @ 01.07.15, 09:22

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

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

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

Добавлено 01.07.15, 09:50

Цитата Serafim @ 01.07.15, 09:22

А тут какой-то Objective-C, только в профиль =)

А что общего? В Objective-C методы как раз в словариках ищутся.

DarkEld3r, видимо, имел в виду, что ассоциативный массив с константным набором ключей и структура неотличимы.

Цитата Qraizer @ 01.07.15, 10:11

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

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

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

Выделяется тут разве что D, с его возможность обработать нереализованные методы.

Цитата Qraizer @ 01.07.15, 10:11

DarkEld3r, видимо, имел в виду, что ассоциативный массив с константным набором ключей и структура неотличимы.

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

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

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

Короче да, наверное стоит всё же поподробнее разобраться в чём у них там основной замут. Хотя если настаиваете - могу дальше выдвигать псевдотеории на тему "классы рулят".

Добавлено 01.07.15, 11:11

Цитата Qraizer @ 01.07.15, 10:11

DarkEld3r, видимо, имел в виду, что ассоциативный массив с константным набором ключей и структура неотличимы.

+1

Добавлено 01.07.15, 11:13
имея на руках, допустим лексему StructEntity, туда можно подсунуть, как эту структуру, так и ассоциативный массив, главное чтоб совпадали нужные поля для последующей компиляции.

Цитата Serafim @ 01.07.15, 11:10

С другой стороны в пыхе есть и интерфейсы, и трейты, и поведение у них совершенно разное...

Если не лень и можно объяснить в двух словах, то я бы с удовольствием послушал.

С другой стороны не всё так просто будет при сборке, в байткод JVM, там вообще желательно привязывать все сущности к реально существующим в Java. Но это уже оффтоп. Просто небольшое исключение из правил (растовая структура == хеш).

Добавлено 01.07.15, 11:25

Цитата DarkEld3r @ 01.07.15, 11:13

Если не лень и можно объяснить в двух словах, то я бы с удовольствием послушал.

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

Трейты же - это набор некой логики, которые можно использовать в качестве источников методов\полей и резолвить их налету. Т.е. тупо примеси:

trait A {
    public function some(){}
}
 
tarit B {
    public function some(){}
}
 
 
class Main {
  // Через use подрубаем в класс, но т.к. имена конфликтуют, нужно воспользоваться резолвом
  use A, B {
    B::some insteadof A; // Ставим метод some из B "выше", нежели А. Т.е. перекрываем, так сказать один другим.
    B::some as any; // Если нужно оба, то переименовываем метод some в any, внутри класса Main
  }
}

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

trait StringifyObject
{
    public function toString()
    {
        return '<Object#' . static::class . '>';
    }
}
 
class Some {
  use StringifyObject;
}
 
echo (new Some)->toString();

Сообщение отредактировано: Serafim - 01.07.15, 11:30

Цитата D_KEY @ 01.07.15, 09:44

В чем отличие?

Интерфейс - это тип задающий набор методов, которые необходимо реализовать, а трейт - это просто набор условий.
Условиями может быть наличие каких-то методов подобно интерфейсу, а может быть возможность неявно кастоваться к заданному типу, или иметь возможность быть вызванным как функция с двумя любыми параметрами, или быть целым числом, или уметь сериализоваться в строку библиотекой СуперСериализатор. Все что душе угодно и позволяет язык. Разницу чувствуешь?
Для того чтобы унаследоваться от интерфейса, объект должен быть классом и "знать" об этом интерфейсе, а вот трейту может соответствовать объект любого типа: скаляр, массив, хэш, структура, класс, что угодно. И этот объект не обязан ничего "знать" об этом трейте. Это полезно.

Например в D есть трейт isInputRange. Любой объект для которого определены примитивы - empty, popFront, и front будут удовлетворять этому трейту. Мне не нужно наследоваться или как-то еще привязываться к isInputRange. Мне достаточно просто описать эти методы. Любой объект O, для которого компилируются O.empty, O.popFront и O.front будет считаться InputRange.

Можно взять произвольный написанный левым дядей объект и самому дописать функции empty(O), popFront(O) и front(O) и благодаря UFCS объект ничего не знающий о трейте isInputRange внезапно начинает ему соответствовать.

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

В D полно трейтов из серии isArray, isNumeric, isMutable, isCallable и так далее.

Возможны ли такие фокусы в Rust?

Сообщение отредактировано: applegame - 01.07.15, 21:11

Цитата applegame @ 01.07.15, 21:08

Интерфейс - это тип задающий набор методов, которые необходимо реализовать, а трейт - это просто набор условий.
Условиями может быть наличие каких-то методов подобно интерфейсу, а может быть возможность неявно кастоваться к заданному типу, или иметь возможность быть вызванным как функция с двумя любыми параметрами, или быть целым числом, или уметь сериализоваться в строку библиотекой СуперСериализатор. Все что душе угодно и позволяет язык. Разницу чувствуешь?
Для того чтобы унаследоваться от интерфейса, объект должен быть классом и "знать" об этом интерфейсе, а вот трейту может соответствовать объект любого типа: скаляр, массив, хэш, структура, класс, что угодно. И этот объект не обязан ничего "знать" об этом трейте. Это полезно.

Например в D есть трейт isInputRange. Любой объект для которого определены примитивы - empty, popFront, и front будут удовлетворять этому трейту. Мне не нужно наследоваться или как-то еще привязываться к isInputRange. Мне достаточно просто описать эти методы. Любой объект O, для которого компилируются O.empty, O.popFront и O.front будет считаться InputRange.

А зачем, при наличии таких гибких и удобных трейтов, иметь ещё и интерфейсы?

Сообщение отредактировано: korvin - 01.07.15, 21:57

applegame, мой вопрос был об отличии trait'ов в Rust от неких "нормальных" trait'ов.

Добавлено 01.07.15, 22:28

Цитата applegame @ 01.07.15, 21:08

Интерфейс - это тип задающий набор методов, которые необходимо реализовать, а трейт - это просто набор условий.

Это зависит от языка.

Цитата korvin @ 01.07.15, 21:57

А зачем, при наличии таких гибких и удобных трейтов, иметь ещё и интерфейсы?

ИМХО, интерфейсы это в первую очередь динамический полиморфизм, а трейты скорее статический. И я считаю, что смешивать их в одну кучу - не очень хорошая идея. По крайней мере в C/C++ подобных языках.

Цитата D_KEY @ 01.07.15, 22:25

Это зависит от языка.

Зависит.В С++ и D, насколько я понимаю, трейты как раз то, что я описал.

Сообщение отредактировано: applegame - 02.07.15, 06:36

Цитата applegame @ 02.07.15, 06:33

Зависит.В С++ и D, насколько я понимаю, трейты как раз то, что я описал.

В C++ нет ни интерфейсов, ни трейтов А в D вроде так, да. И ты разбираешься в D намного лучше меня, так что тут спорить не стал бы.

По моему, все стали рассказывать о том, что такое трейт в их любимом языке.

Цитата D_KEY @ 02.07.15, 07:00

В C++ нет ни интерфейсов, ни трейтов

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

Цитата applegame @ 01.07.15, 21:08

Возможны ли такие фокусы в Rust?

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

Очевидный минус - надо подумать какие трейты реализовывать, ну и невозможность заранее удовлетворить всем будущим трейтам. Как плюс можно назвать то, что не получится так, что у типа реализованы нужные функции, но с другой семантикой, а трейту он при этом соответствовать будет. Заранее предвижу аргумент о том, что вероятность мала и спорить особо не буду. Сигнатуры ведь тоже проверяются, не только имена?

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

Цитата DarkEld3r @ 02.07.15, 08:27

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

А что, по-вашему, является интерфейсом в C++?

Правильный ответ

Концепты

Цитата MyNameIsIgor @ 02.07.15, 08:33

А что, по-вашему, является интерфейсом в C++?

Да то же, что и в D - абстрактные классы.

Цитата MyNameIsIgor @ 02.07.15, 08:33

Концепты

А как же "интерфейсы это в первую очередь динамический полиморфизм"?