пошел проверять

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

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

это же большая нагрузка, знать, виртуальный ли метод, какой когда вызовется

сарказм?

да нет, я серьезно пишу

это же большая нагрузка, знать, виртуальный ли метод, какой когда вызовется

Крестопроблемы

ну типа я кресты не осилил в свое время

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

это же большая нагрузка, знать, виртуальный ли метод, какой когда вызовется

В Java к примеру метод всегда виртуальный (за исключением в некоторых случаях final, но их и переопределять нельзя)

слишком много тонкостей

бля

открыл c++ repl понял сколько нужно заморочек написать, чтобы это запустилось и закрыл

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

боюсь в крестах ООП - не самая сложная фича

боюсь в крестах ООП - не самая сложная фича

ну мне лично с динамикой было сложновато

Child foo = new Parent() foo->doSmth() будет вызван у чайлда

Не, так не работает, причём нигде. Ребёнок может мимикрировать под родителя, не наоборот.

В Java к примеру метод всегда виртуальный (за исключением в некоторых случаях final, но их и переопределять нельзя)

local variables referenced from lambda expression must be final

это же большая нагрузка, знать, виртуальный ли метод, какой когда вызовется

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

Не, так не работает, причём нигде. Ребёнок может мимикрировать под родителя, не наоборот.

родитель не может под ребенка?

открыл c++ repl понял сколько нужно заморочек написать, чтобы это запустилось и закрыл

struct Parent { virtual void doSmth() { cout << "Parent"; } }; sturct Child: Parent { virtual void doSmth() { cout << "Child"; } }; int main() { Parent *obj = new Child(); obj->doSmth(); //"Child" }

struct Parent { virtual void doSmth() { cout << "Parent"; } }; sturct Child: Parent { virtual void doSmth() { cout << "Child"; } }; int main() { Parent *obj = new Child(); obj->doSmth(); //"Child" }

структуры?

сириусли?

Не хочу тебя расстраивать

родитель не может под ребенка?

Нет. У него же ФИЗИЧЕСКИ может не хватать какой-то фичи у класса.

но в C++ структура и класс - это почти одно и тоже

это шарп

там отличия косметические

угадайте вывод

давненько я на плюсах не писал

)

вплоть до наследования структур от классов, и классов от структур

там даже ошибка есть, которая внезапно меняет вывод

госпади как это же это сложно

давненько я на плюсах не писал

так и в том же TS то же будет. Тебе компилятор вежливо скажет, что "так как у родителя в прототипе не хватает вот этого и этого, то ребёнком ему не быть". Это вполне себе универсальное правило

родитель не может под ребенка?

Может при контравариантном сабтайпинге

Нет. У него же ФИЗИЧЕСКИ может не хватать какой-то фичи у класса.

в движке сорс там такие жесткие касты… прост пздц

local variables referenced from lambda expression must be final

Не надо путать финальные переменные и финальные методы.

1 2 2

1 2 2

111

Не надо путать финальные переменные и финальные методы.

Поговорил с копипастой — день прошёл не зря

Может при контравариантном сабтайпинге

подробнее, плз =)

а если сделать public f, то 1 1 2

родитель не может под ребенка?

родитель сможет стать ребёнком если его скастовать

явно скастовать конечно же

111

а не overide забыли?

а с override уже ну будет virtual

разные virtual в крестах и не в крестах

а с override уже ну будет virtual

не, вроде в шарпе без override нельзя

просто варнинг, ошибки нет

ааа

но override - это просто указание больше для программиста, что идёт переопределение виртуального метода

так. Горшочек, не вари! Я не думал, что мой вопрос про разницу типов и значений в TS вызовет обсуждение особенностей полиморфизма разных языков =)

И да, возвращаясь к наследованию.

в языках типа Java и C# вообще без наследования нельзя никак

(я имею ввиду конечно же наследование классов, а не имплементацию интерфейсов, что немножко другое)

в языках типа Java и C# вообще без наследования нельзя никак

Это исключительно их головняк

Ну так и в каком-нибудь реакте не получится без наследования фактически

правда его спрятать в HOC можно

но всё таки

явно скастовать конечно же

Опять магия вне Хогвартса

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

когда наследование вырастает до цепочки в 5-6 классов и ты явно не видишь инициализаций

ну тут всё правильно, Foo - родитель, Bar - потомок

так да

правда его спрятать в HOC можно

Это называется альтернативным решением

давно это было =) Да, вот ровно так и можно =)

когда наследование вырастает до цепочки в 5-6 классов и ты явно не видишь инициализаций

сиди потом и думай, какой, сук, метод будет вызван

и у кого

ну вот глубокое наследование как правило как раз и приносит проблемы

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

особенно игровые движки этим грешат

хм

но в принципе на производительность глубокое наследование особо и не влияет

а это для крестовиков самое главное

ну вот глубокое наследование как правило как раз и приносит проблемы

Как определить, что наследование достаточно глубокое

я бы даже сказал "почти не влияет"

Как определить, что наследование достаточно глубокое

ну вот родитель-ребёнок1 явно нельзя назвать глубоким, родитель-ребёнок1-ребёнок2 - уже чуть хуже, но думаю терпимо, а вот глубже - уже пожалуй стоит избегать

Опосредованно -- влияет. У тебя появляется куча кода, которая выполняется просто потому, что "базовый класс недостаточно базовый и несет на себе лишний базовый функционал". И это "просачивается" в наследников.

Кроме того, у тебя появляется ситуация, когда ты не совсем понимаешь, как именно будет вести себя объект, который ты наследуешь -- по тем же причинам -- и ты слишком легко можешь ОШИБИТЬСЯ про оценке

ну вот родитель-ребёнок1 явно нельзя назвать глубоким, родитель-ребёнок1-ребёнок2 - уже чуть хуже, но думаю терпимо, а вот глубже - уже пожалуй стоит избегать

то есть делать можно только одно наследование

ведь Object)

не, Object не учитывается

там в основном служебная функциональность и она достаточно редко переопределяется

к тому же в тех же крестах нет Object или другого базового для всех класса

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

по крайней мере не во всех ситуациях точно

блин. Да не бывает серебряной пули, нигде и никогда. Заменить везде по всему миру? Точно говно получится, инфа 100%. Заменить в твоём личном проекте? Ну, покажи проект сначала

Наследование, композиция, включение, ..., много их -- это замечательные инструменты, которыми стоит пользоваться тогда, когда надо. Рассуждать про то, что "молоток лучше гвоздодёра" -- глупо. Использовать молоток вместо гвоздодёра потому, что "молотки -- отстой" -- еще больший идиотизм

но в принципе на производительность глубокое наследование особо и не влияет

динамическая диспетчеризация влияет же

динамическая диспетчеризация влияет же

почти нет. Ты вынужден создать по лишней хеш-таблице на каждый тип (не экземпляр!), и всё. Проседания по быстродействию -- +1 JUMP, по памяти тоже несерьёзно

динамическая диспетчеризация влияет же

Насколько я понимаю, она не становится медленней с увеличением глубины наследования.

не становится.

(ну, не ты вынужден, а компилятор, разумеется)

почти нет. Ты вынужден создать по лишней хеш-таблице на каждый тип (не экземпляр!), и всё. Проседания по быстродействию -- +1 JUMP, по памяти тоже несерьёзно

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

почти нет. Ты вынужден создать по лишней хеш-таблице на каждый тип (не экземпляр!), и всё. Проседания по быстродействию -- +1 JUMP, по памяти тоже несерьёзно

там будет даже не jump, а что-то похожее на call [eax + 4]

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

А на каком языке проект-то был?

или что-то такое

ребята, может есть у кого на примете англоговорящее кромьюнити по ts в телеграме?