V
то есть в коллстеке из 10 функций у нас 1024 варианта кто как кого зовет, я правильно тебя понял?
чего?
Size: a a a
2020 March 03
V
вариант у нас только 1 у нас же статическая типизация
AZ
чего?
как солвер будет выбирать подходящие функции? Особенно если у нас еще перегрузка функций возможна то ваще пипец
p
Как пример - сериализация без рефлексии. Делаешь трейт:
Ты хочешь обьявить такую свою абстракцию для примитивных типов и типов из стандратной библиотеки.
И в случае интерфейсов тебе бы пришлось городить адаптеры, чтобы такой дизайн работал, либо делать решение через рефлексию, где теряются компайл-тайм проверки того, что данный тип можно сериализовать.
А в случае тайпклассов - оно работает из коробки, т.к. ты можешь реализовать свои тайпклассы для чужих типов.
Поэтому библиотеки на тайпклассах получаются более модульными и удобными для конечного пользователя без потерь в типобезопасности.
trait MySerialization {
fn serialize(&self) -> Vec<u8>
}Ты хочешь обьявить такую свою абстракцию для примитивных типов и типов из стандратной библиотеки.
И в случае интерфейсов тебе бы пришлось городить адаптеры, чтобы такой дизайн работал, либо делать решение через рефлексию, где теряются компайл-тайм проверки того, что данный тип можно сериализовать.
А в случае тайпклассов - оно работает из коробки, т.к. ты можешь реализовать свои тайпклассы для чужих типов.
Поэтому библиотеки на тайпклассах получаются более модульными и удобными для конечного пользователя без потерь в типобезопасности.
То есть разница между интерфейсом и типажем что первый нельзя реализовывать для чужих типов?
p
Лол
p
А что такое "чужой" тип в шарпе?
EG
И ещё есть протоколы, которые умеет проверять mypy
AZ
А что такое "чужой" тип в шарпе?
интерфейсы можно реализовывать только в объявлении типа, трейты - в других местах
EG
Это уже структурная типизация, как интерфейсы в го
AZ
То есть разница между интерфейсом и типажем что первый нельзя реализовывать для чужих типов?
чтобы было понятно - схожим образом работают атрибуты в расте. Ты не можешь повесить свой атрибут на чужую структуру, на Vec например
DS
То есть разница между интерфейсом и типажем что первый нельзя реализовывать для чужих типов?
Не только.
У тайпклассов ещё есть механизм через который автоматически прокидываются инстансы в друг друга.
А-ля, если есть реализация MyTrait для типа X и impl <T: MyTrait > MyTrait for Option<T>, то методы тайпклассы автоматически будут доступны и у Option<X>
У тайпклассов ещё есть механизм через который автоматически прокидываются инстансы в друг друга.
А-ля, если есть реализация MyTrait для типа X и impl <T: MyTrait > MyTrait for Option<T>, то методы тайпклассы автоматически будут доступны и у Option<X>
V
как солвер будет выбирать подходящие функции? Особенно если у нас еще перегрузка функций возможна то ваще пипец
будет выбирать ту функцию, которая лучше всего подходит. Тоесть если у объекта
o: {
f: ()->()
f: ()->()&u32->()
f<T>: ()->T
}
и мы вызываем
let unit: () = o.f(), то будет вызвана первая функция, тк она имеет самый узкий тип (хотя вторая и третья тоже подходят по сигнатуре), попутно тебе компилятор засрёт всё ворингами, тк вторая функция никогда не будет вызвана с параметром по-умолчанию
o: {
f: ()->()
f: ()->()&u32->()
f<T>: ()->T
}
и мы вызываем
let unit: () = o.f(), то будет вызвана первая функция, тк она имеет самый узкий тип (хотя вторая и третья тоже подходят по сигнатуре), попутно тебе компилятор засрёт всё ворингами, тк вторая функция никогда не будет вызвана с параметром по-умолчанию
p
интерфейсы можно реализовывать только в объявлении типа, трейты - в других местах
Пока не вижу между ними принципиальных различий еще
p
Типажи улучшенная версия интерфейсов
λ
То есть разница между интерфейсом и типажем что первый нельзя реализовывать для чужих типов?
Тайпклассы выгодно отличается от модулей, а значит и от классов и интерфейсов в оопе, тем что в языках с ними есть для них автоматический солвер.
AZ
будет выбирать ту функцию, которая лучше всего подходит. Тоесть если у объекта
o: {
f: ()->()
f: ()->()&u32->()
f<T>: ()->T
}
и мы вызываем
let unit: () = o.f(), то будет вызвана первая функция, тк она имеет самый узкий тип (хотя вторая и третья тоже подходят по сигнатуре), попутно тебе компилятор засрёт всё ворингами, тк вторая функция никогда не будет вызвана с параметром по-умолчанию
o: {
f: ()->()
f: ()->()&u32->()
f<T>: ()->T
}
и мы вызываем
let unit: () = o.f(), то будет вызвана первая функция, тк она имеет самый узкий тип (хотя вторая и третья тоже подходят по сигнатуре), попутно тебе компилятор засрёт всё ворингами, тк вторая функция никогда не будет вызвана с параметром по-умолчанию
ты ведь понимаешь что в выводе типов уравнения в обратную сторону тоже распространяются, в отличие от вывода в каких-нибудь шарпах? Например
let s = "123".parse();
let vec = Vec::with_capacity(s); // тут раст выводит, что parse на предыдущей строке это parse::<usize>AZ
Пока не вижу между ними принципиальных различий еще
в сишарпе невозможно сделать библиотеку num-traits
p
в сишарпе невозможно сделать библиотеку num-traits
А это что
AZ
Пока не вижу между ними принципиальных различий еще
и это охреннная разница, к слову
AZ
короч окей