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

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

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

Так в том и дело, что "интерфейсы" и "трейты" зависят от языка.

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

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

А при чём тут я?

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

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

Если добавить концепты, то разве останутся сомнения?

Цитата D_KEY @ 02.07.15, 09:21

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

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

Если добавить концепты, то разве останутся сомнения?

Концепты не добавят функциональности.
И я вообще не понимаю как сравниваются плюсовые шаблоны и растовые трэйты...

Цитата MyNameIsIgor @ 02.07.15, 09:20

А при чём тут я?

Действительно не при чём, ошибся. Но с этим мнением я согласен. Можем поспорить.

Цитата D_KEY @ 02.07.15, 09:21

Если добавить концепты, то разве останутся сомнения?

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

Добавлено 02.07.15, 09:36

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

И я вообще не понимаю как сравниваются плюсовые шаблоны и растовые трэйты...

Растовые дженерики. В них нельзя, как в С++, делать с аргументами что угодно с проверкой после подстановки параметров. "Границы" типов жестко задаются как раз трейтами. То есть, если для каждого параметра прописывать ограничения при помощи концептов, то получится нечто похожее.

Сообщение отредактировано: DarkEld3r - 02.07.15, 09:37

Цитата DarkEld3r @ 02.07.15, 09:35

Можем поспорить

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

Добавлено 02.07.15, 09:40

Цитата DarkEld3r @ 02.07.15, 09:35

Растовые дженерики

Вот я и говорю - как вы так сравнили шаблоны и трейты? Я не понял. По каким параметрам?

Цитата DarkEld3r @ 02.07.15, 09:35

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

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

Цитата MyNameIsIgor @ 02.07.15, 09:38

Вы говорите об интерфейсах исключительно в их понимании в ООП.

Тогда почему я ошибаюсь? "Границы"-то мы не оговаривали. А уж контекст был про трейты/интерфейсы в D.

Цитата MyNameIsIgor @ 02.07.15, 09:38

Вот я и говорю - как вы так сравнили шаблоны и трейты? Я не понял. По каким параметрам?

Я надеюсь тут опять не казуистика? Тогда сравнили напрямую - по их предназначению. А именно написанию обобщённого кода. И ещё раз: не шаблоны и трейты, а шаблоны, которые могут (в перспективе) быть ограничены концептами и дженерики, которые обязательно ограничены трейтами.

Цитата MyNameIsIgor @ 02.07.15, 09:38

И это fail.

Нет.

Цитата MyNameIsIgor @ 02.07.15, 09:38

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

Почему это нельзя?

Цитата DarkEld3r @ 02.07.15, 10:01

Тогда почему я ошибаюсь?

Потому что мы говорим об интерфейсах в языке. В мультипарадигменном языке C++. А не в одной из школ ООП.
По-вашему получается, что встроенные типы интерфейса не имеют. Я же вижу std::function - вполне себе использование интерфейса в классическом понимании.

Цитата DarkEld3r @ 02.07.15, 10:01

"Границы"-то мы не оговаривали.

Как же это?

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

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

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

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

Цитата DarkEld3r @ 02.07.15, 10:01

Почему это нельзя?

Так я понял ваше объяснение. Я вас не так понял? Вы утверждаете, что в Rust можно соорудить аналог std::map, у которого будет аналог operator[], создающий объект конструктором по-умолчанию при его отсутствии в словаре, и при этом этот аналог можно будет инстанцировать типом без конструктора по умолчанию?

Сообщение отредактировано: MyNameIsIgor - 02.07.15, 10:17

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

Концепты не добавят функциональности.

Ну...

Цитата

И я вообще не понимаю как сравниваются плюсовые шаблоны и растовые трэйты...

Я так понимаю, что имеются в виду дженерики + трейты.

Добавлено 02.07.15, 10:33

Цитата MyNameIsIgor @ 02.07.15, 09:38

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

Ну в трейте для элемента у контейнера не будет этого требования, а в требованиях метода - будет. По-моему так.

Сообщение отредактировано: D_KEY - 02.07.15, 10:34

Цитата D_KEY @ 02.07.15, 10:28

Ну в трейте для элемента не будет этого требования, а в требованиях метода - будет. По-моему так.

Подобные примеры мне пока не попадались.

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

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

Не совсем. В D есть ключеве слово interface. Абстрактные классы тоже есть, но они отличаются. Это не суть.

В общем смысле концепты несомненно являются интерфейсами. Но разве ООП-интерфейсы жабы или D не являются интерфейсами в общем смысле? И то и другое является подмножеством интерфейсов в общем смысле. Говоря о динамическом полиморфизме я имел ввиду интерфейсы в узком смысле, а именно ООП-ные интерфейсы.

Основное отличие ООП-ных интерфейсов и концептов как раз в статичности/динамичности. Опять же берем в качестве примера D (можно считать что это некий вариант C++ с концептами):

auto sort(R)(R range) if(isRandomAccessRange!R) {
   ...
}

Функция sort принимает любой тип удовлетворяющий концепту (он же является и trait-ом) isRandomAccessRange. Но такие "интерфейсы" могут принимать в качестве параметра только шаблонные функции. Статический полиморфизм. Как нам создать вектор произвольных объектов с интерфейсом isRandomAccessRange? Только написав некий враппер с применением, внезапно, ООП-ных интерфейсов.

Поэтому разделение трейтов/концептов и ООП-интерфейсов на две разные, но взаимодополняющие сущности мне представляется вполне разумным. В Rust, насколько я понял, попытались как-то объединить в единую сущность. Насколько это можно удачно реализовать в языках со статической типизацией трудно сказать. Главный вопрос: зачем? ООП-интерфейсы + концепты отлично себя показали, к чему изобретать велосипед?

Цитата applegame @ 02.07.15, 10:49

В Rust, насколько я понял, попытались как-то объединить в единую сущность. Насколько это можно удачно реализовать в языках со статической типизацией трудно сказать. Главный вопрос: зачем?

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

Цитата D_KEY @ 02.07.15, 10:53

Затем, что не надо "один и тот же" интерфейс(в широком смысле слова) описывать дважды. И оберток никаких не надо.

Хм. А как описать в Rust интерфейс/трейт isMutable или допустим isImplicitlyConvertible. Думаю из названия понятно что это за интерфейсы. Возможно я ошибаюсь, но не являются ли растовские трейты по сути теми же ООП-ными интерфейсами, вид сбоку?

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

Цитата applegame @ 02.07.15, 11:01

Хм. А как описать в Rust интерфейс/трейт isMutable или допустим isImplicitlyConvertible.

Давай начнем с задачи, а то ты уже про реализацию спрашиваешь. Что нужно-то?

Добавлено 02.07.15, 11:04
И как их описать в D?

Цитата applegame @ 02.07.15, 10:49

В общем смысле концепты несомненно являются интерфейсами. Но разве ООП-интерфейсы жабы или D не являются интерфейсами в общем смысле? И то и другое является подмножеством интерфейсов в общем смысле.

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

Цитата applegame @ 02.07.15, 10:49

Основное отличие ООП-ных интерфейсов и концептов как раз в статичности/динамичности

Нет. Динамическая диспетчеризация просто вытекает из ООП. Поэтому главное отличие - говорим мы только об ООП или же вообще.

Цитата applegame @ 02.07.15, 10:49

Функция sort принимает любой тип удовлетворяющий концепту (он же является и trait-ом) isRandomAccessRange. Но такие "интерфейсы" могут принимать в качестве параметра только шаблонные функции. Статический полиморфизм.

Это зависит от языка. Применительно к C++ - да. Затирать тип придётся вручную. Но вот есть C#. Там помимо ООП-интерфейсов есть ограничения на параметры обобщений, которые как и сами по себе интерфейсы в некотором смысле, так и могут требовать реализации ООП-интерфейсов. Так вот там это будет динамический полиморфизм, компилятор не станет инстанцировать обобщение для каждого типа, а затрёт тип. Т.е. наблюдается противоположная C++ ситуация.
Потому вполне себе можно вообразить язык, где компилятор способен делать и то, и то. И такая функция будет как статически, так и динамически полиморфна.

Вывод: интерфейсы ортогональны способу диспетчеризации.

Цитата applegame @ 02.07.15, 10:49

Только написав некий враппер с применением, внезапно, ООП-ных интерфейсов.

ООП-интерфейсы не единственный способ (по крайней мере в плюсах) обеспечения динамической диспетчеризации.

Добавлено 02.07.15, 11:06

Цитата applegame @ 02.07.15, 11:01

Возможно я ошибаюсь, но не являются ли растовские трейты по сути теми же ООП-ными интерфейсами, вид сбоку?

Именно ими они и являются.

Сообщение отредактировано: MyNameIsIgor - 02.07.15, 11:07