Как я понял , тайпклассы - способ навесить дополнительный функционал на некоторое множество типов

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

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

Мне кажется, ты намекаешь на какую-то конкретную реализацию имплиситов ;)

Я бы сказал, в конкретном языке

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

У тайпклассов тоже есть такая проблема, кстати (по крайней мере, раньше в Haskell была) — нельзя было их отдельно импортировать из модуля. Сейчас починили?

Но это проблемы не принципиальные, а просто не очень большие (как по мне) дырки в конкретных реализациях.

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

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

Например?

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

Ой, там были проблемы с импортом инстансов, да.

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

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

Например?

Я те щас покажу пример

Пример: ты говоришь, что есть нечто, потенциально сериализуемое в JSON. Это нечто всегда имеет метод toJSON

При этом сериализоваться могут многие типы

В т.ч. и не твои

А где правила сериализации прописываются и детали?

Простой и понятный доброму человеку пример: https://github.com/ForNeVeR/EvilPlanner/blob/dd44d11895b3d61b592fb4599117367ed57c2222/EvilPlanner.Logic/DatabaseExtensions.fs#L15-L33

И соль тайпклассов в том, что реализация поведения лежит отдельно от типа, либо отдельно от класса

Вощм, фишка в том, что можно дореализовать данное кем-то поведение для своих типов. И дореализовать твоё поведение для чужих типов. Не имея исходников

А компилятор следит за тем, чтобы некое конкретное поведение для некоего конкретного типа было реализовано ровно один раз (если реализовано вообще, конечно)

Простой и понятный доброму человеку пример: https://github.com/ForNeVeR/EvilPlanner/blob/dd44d11895b3d61b592fb4599117367ed57c2222/EvilPlanner.Logic/DatabaseExtensions.fs#L15-L33

У меня есть типы IQueryable<T> и DbRawSqlQuery<T>. Я хочу функцию singleOrDefaultAsync, которая бы делала понятно что для обоих типов. При этом у меня на одном типе есть обычный метод this.SingleOrDefaultAsync, а на другом типе есть статический экстеншен QueryableExtensions.SingleOrDefaultAsync (т.е. через SRTP это разрулить невозможно). Оба типа — не мои. Но я хочу, чтобы мой код работал прозрачно вне зависимости от того, какой из этих типов туда передали.

У меня есть типы IQueryable<T> и DbRawSqlQuery<T>. Я хочу функцию singleOrDefaultAsync, которая бы делала понятно что для обоих типов. При этом у меня на одном типе есть обычный метод this.SingleOrDefaultAsync, а на другом типе есть статический экстеншен QueryableExtensions.SingleOrDefaultAsync (т.е. через SRTP это разрулить невозможно). Оба типа — не мои. Но я хочу, чтобы мой код работал прозрачно вне зависимости от того, какой из этих типов туда передали.

...я таки умудрился сделать это на SRTP (спрашивал на SO и мне подсказали, как делать правильно), но у моей реализации проблема. Каждый раз, когда мне нужно добавить новый тип в набор типов, поддерживаемых функцией singleOrDefaultAsync, мне нужно идти вот в этот самый файл и туда вносить исправления. В общем-то, нарушается SRP. У нормальных тайпклассов бы такого ограничения не было, и я бы мог писать реализации для тайпкласса где угодно — в любом файле, модуле, сборке. И моя функция singleOrDefaultAsync бы с таким типом могла работать.

ну кароче речь о том, какой из маханизмов для ad-hoc polymorphism лучш

Да дайте хоть какой-нибудь :)

о/

Щас будет реклама отдыха))

ну блин, ооп оно такое. если у тебя встает задача подобного вида, то ковыляешь в сторону объектов-компаньонов. если у тебя есть объекты типов T1 и T2, для которых нужно одинаковое поведение, и они не унифицированы. тип фигачишь IQueryExecutor<T> и лепишь имплементации для T1 и T2

Щас будет реклама отдыха))

Если будет — разберёмся. А до тех пор у нас действует презумпция.

ну блин, ооп оно такое. если у тебя встает задача подобного вида, то ковыляешь в сторону объектов-компаньонов. если у тебя есть объекты типов T1 и T2, для которых нужно одинаковое поведение, и они не унифицированы. тип фигачишь IQueryExecutor<T> и лепишь имплементации для T1 и T2

Нихачу!

ООП — да, оно такое. Но есть же SRTP, который прям самым естественным образом эту задачу решает.

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

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

Она даже не выглядит очень уж сложной

я не знаю, что такое SRTP

И совсем напрасно.

Стоит ознакомиться.

SRTP это инлайн, кароч.

Собственно, метапрограммирование на F# — это как раз про SRTP и тайп-провайдеры. Не про ООП.

а расшифровывается как?

Statically Resolved Type Parameters

а, ясно.

ну кароче, это приконьно, но костыль уровня c++.

Ну, если говорить про C++20 (концепты).

«Костыль» уровня блидинг-эдж метапрограммирования на C++. Неплохо, я б хотел такой костыль.

А, подождите, он же у меня есть ?

по-моему, шаблоны плюсов уже давно мощнее чем SRTP

Они про другое.

Концепты про то же самое.

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

А вот SRTP присутствуют в системе типов.

@fvnever я так и не понял, как бы тебе помог тайпкласс в твоем случае

Поэтому возможности инструментов разные.

ну так и SRTP отсутствует. инлайн и полтора констрейна.

@fvnever я так и не понял, как бы тебе помог тайпкласс в твоем случае

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

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

ну так и SRTP отсутствует. инлайн и полтора констрейна.

Ну, это и есть SRTP. Если у тебя есть какие-то ещё определения для SRTP — поделись, пожалуйста.

Где прописывается поведение, когда надо вызвать статический метод, а когда нет?

ну и что тут про систему типов?

ну и что тут про систему типов?

Посмотри тип какой-нибудь SRTP-функции.

Давай вот на примере.

посмотри на какой-нибудь шаблон. тоже самое. только там выбор средств побогаче

C++: template<class T> auto foo(T& x, T& y) -> decltype(x + y) { return x + y; }

Какой тип у этой функции?

Вообще-то хрен его знает, какой. Никакого нету.

Но про оператор + в этом типе ничего не сказано.

А теперь то же самое на F#: let inline foo a b = a + b

Какой тип у этой функции? Правильно — такой, который требует оператор + между a и b.

и ф чем ты видишь концептуальную разницу?

Кстати

Ну, на C++ нам там повезло, конечно, что у меня возвращаемый тип с плюсом

Можно другой пример выдумать, без decltype, где вообще непонятно будет.

Если я ниже напишу let x = foo 2 3

и ф чем ты видишь концептуальную разницу?

Я указал.

Какой тип выведет?

Какой тип выведет?

int же.

2 и 3 — инты.

А если функция обобщенная нужна?

Тогда будь добр, пиши обобщённо.

Например, будет работать let inline foo2 a b = foo a b, тут будет правильный тип.

Если уж упарываться по полной, то надо 'a->'a->'b

Только не ', а ^

(хотя они тут взаимозаменяемы, кажется?)

Да, ты прав

Хотя надо проверять

Какой тип у этой функции? Правильно — такой, который требует оператор + между a и b.

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

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

Нет, в плюсах не то же самое.

То же самое в плюсах — концепты.

Концепты будут в C++20.

В плюсах развернется препроцессором

Насколько я помню

В плюсах развернется препроцессором

Что ты, что ты!

Нет!

В местах конкретного вызова

Не?

Неееет

Хммм... всегда считал, шо шаблоны - те же макросы

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