p
Чтобы вот такой херни не было
да нет сложности, невыявленная абстракция это цена в поддержке
перебивать id с int на long ручками, и хорошо если это id назвали одинаково
Size: a a a
2021 January 12
CD
еще хуже, что там кроме id может найтись еще одно очень важное общее поле
CD
а еще рано или поздно можно кодить проверки типами и тогда int будет на id_type перебит
p
еще хуже, что там кроме id может найтись еще одно очень важное общее поле
В расте я бы делал
trait HasField {
fn field() -> &T;
}
trait HasField {
fn field() -> &T;
}
CD
когда прод ляжет из-за того, что кто-то порядок id и size перепутал
p
Если же полиморфной работы не надо - лучше копипастить.
CD
В расте я бы делал
trait HasField {
fn field() -> &T;
}
trait HasField {
fn field() -> &T;
}
это такое же наследование
p
это такое же наследование
Нет
p
Это для полиморфной работы
CD
Нет
да, трейты это компильтаймовый аналог наследования
p
Нет
CD
трейты = закрытое компильтаймовое
наследование = закрытое рантаймовое
наследование = закрытое рантаймовое
CD
закрытое не то слово, как там это называлось-то
CD
Это для полиморфной работы
тебя не удивляет, что конвертация в интерфейс происходит добавлением одного слова dyn?
а
трейты = закрытое компильтаймовое
наследование = закрытое рантаймовое
наследование = закрытое рантаймовое
В C++ классы наследуются и для этого не нужно vtable (если нет виртуальных методов)
а
компильтаймовое наследование
p
тебя не удивляет, что конвертация в интерфейс происходит добавлением одного слова dyn?
И боксингом
ΑZ
В расте я бы делал
trait HasField {
fn field() -> &T;
}
trait HasField {
fn field() -> &T;
}
тебе все ещё его надо руками прописывать
а
vtable нужен только для typeid, виртуальных методов и прочей фигни
ΑZ
хочется это автоматизировать