Система букмекера была гвоздями прибита к модели команда против команды, где ставки делались на 1 или 2. А когда участников больше 2 - проблемы. Тогда сделали много участников, но потом выяснилось что можно делать ставки не только на собаку, но и на будку, из которой собака бежит (очень странно, да, но вот так), типа тебе пофигу. И тогда будки добавили как участников соревнований, для которых точно так же проводился расчет добежала будка или нет. В дебаг вью будки бежали наравне с собаками до финишной прямой

ФП часть фшарпа отвергает наследование реализации. Рекорды и Ду только интерфейсы наследуют

На самом деле, я не понимаю, почему. Мне кажется, что тайпклассы — это прям наследование реализации в чистом виде.

И на них все радуются

На самом деле, я не понимаю, почему. Мне кажется, что тайпклассы — это прям наследование реализации в чистом виде.

Но у нас их нет!

И тайпклассы это композиция

Типа накидал тайпклассов, получил что хочешь

Композиция не мешает, получается, наследовать реализацию.

Композиция не мешает, получается, наследовать реализацию.

Получается да

В базовом классе пишешь, что (=) = not << (!=), а (!=) = not << (=), и всё.

Потому что там такая же иерархия. Все что монада - функтор

Юзер перегружает одно, а второе наследует

Реализацию наследует! Ужасы!

Ну как с жирафом и животными

И тайпклассы это композиция

Я не вижу, в каком месте они композиция.

Вроде бы наследование как наследование :)

А как у них diamond problem решается?

Я не вижу, в каком месте они композиция.

Ну ты можешь сказать что хочешь монаду с логером здесь

А не просто монаду!

Скомпозировал!

Но когда я какой-то тайпкласс реализую, что я там скажу?

Что я реализую монаду с логгером. Что я композирую при этом?

Но когда я какой-то тайпкласс реализую, что я там скажу?

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

То есть создаёшь отдельно инстанс логера, отдельно инстанс монады

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

Я, признаться, запутался, что за монады с логгерами такие, и как их реализовывать

Композируешь!

То есть создаёшь отдельно инстанс логера, отдельно инстанс монады

Но ведь мне придётся какую-то ебаторию делать, чтобы их в один объект слить

Но ведь мне придётся какую-то ебаторию делать, чтобы их в один объект слить

Нет, в этом бонус

Да как нет?

Да как нет?

Ну так нет

Вот у меня есть def foo[X : Monad with Logger](monal: X) {}

И что, где я тут скомпозировал?

Как мне создать монал?

Пишешь условно type A with Interface Monad with ... .... type A with Interface logger with ...

Ну вот это разве композиция?

Но когда я какой-то тайпкласс реализую, что я там скажу?

вот ты приходишь просто и говоришь лист теперь функтор с такой-то функцией map, а не как в c# где всё гвоздями прибито, если Select то только для IEnumerable, и на выходе только он, а не сам лист.

Это чистое незамутнённое множественное наследование

Вот у меня есть def foo[X : Monad with Logger](monal: X) {}

У тебя где-то должны быть два инстанса X с монадой и Х с логером

На самом деле, я не понимаю, почему. Мне кажется, что тайпклассы — это прям наследование реализации в чистом виде.

не наследование, а сабтайпинг

Они могут быть в либах разных

вот ты приходишь просто и говоришь лист теперь функтор с такой-то функцией map, а не как в c# где всё гвоздями прибито, если Select то только для IEnumerable, и на выходе только он, а не сам лист.

Ты чота про C# непонятное совсем городишь

Я в листе могу написать свой отдельный Select

Потому что IEnumerable — тайпкласс!

Они могут быть в либах разных

Мы тут недавно выясняли-выясняли

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

Я в листе могу написать свой отдельный Select

и куда ты его потом денешь, если тебе скажем Where надо

Не то в Расте, а не то даже в самом Хаскеле

Кажись, я не могу чужой тайпкласс реализовать для чужого типа

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

О да. Берется хуй пойми какой ИНСТАНС если их больше одного

«Потому что пошёл нахер» было официальным ответом

Там же все на честном слове держится

Хаскель только один инстанс разрешает иметь в скоупе

То есть два раза сделать логер для одного типа - хуй

Ахахахах

но ведь... newtype...

но ведь... newtype...

Да, но это шадовинг, не?

нет это новая интерпретация типа

нет это новая интерпретация типа

Ну то есть старый затирается в текущем скоупе

не наследование, а сабтайпинг

Наследование и есть вариант сабтайпинга.

Кажись, я не могу чужой тайпкласс реализовать для чужого типа

Да, это по логичным причинам получается. Потому что иначе придется обязательно использовать импорты для инстансов, и мы получим скаловские имплиситы

Ну то есть старый затирается в текущем скоупе

Нет

Наследование и есть вариант сабтайпинга.

да как это, можно наследоваться без сабтайпинга (теоретически)

Да, это по логичным причинам получается. Потому что иначе придется обязательно использовать импорты для инстансов, и мы получим скаловские имплиситы

Да, спасибо, что послал меня нахер, я уже понял.

Логичные причины.

Ну то есть старый затирается в текущем скоупе

в том же модуле нельзя... наверное

Ну то есть старый затирается в текущем скоупе

Нет, ничего не затирается. Ты создаешь ньютайп и для него делаешь нужный инстанс.

Да, спасибо, что послал меня нахер, я уже понял.

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

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

Я не понимаю, хоть убей, почему это проблема.

Ну реализовали, ну и чо?

Ну то есть старый затирается в текущем скоупе

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

Там, где мне это важно, я же могу конфликт разрешить.

Явно указать, чо я импортирую, ну или явно передать тайп аргументом.

someOtherLibrary.MethodCall<TypeFromLibrary1, TypeClassInstanceFromLibrary2>()

Я не понимаю, хоть убей, почему это проблема.

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

Я не понимаю, хоть убей, почему это проблема.

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

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

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

он ведь дрищет кровью при этом из-за undecidable instance?

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

Разные, ок. Пусть у меня спросит. Я рили не понимаю, в чём проблема.

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

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

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

нда, в скале очередность решает, что тоже в свою очередь не очевидно для программиста, которого не послали нахер за многозначность

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