Разумеется

Если у тебя всё на наследовании, то ты обречён, да

то есть вообще забить на полиморфизм подтипов?

то есть вообще забить на полиморфизм подтипов?

К сожалению, в языках без типажей не получится

ну то есть балуются ж в C++ абстрактными виртуальными классами или всякими интерфейсами в java

К сожалению, в языках без типажей не получится

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

под "далеко" я подразумеваю что-то серьезное

на Js же пишут)

шуткую))

под "далеко" я подразумеваю что-то серьезное

Ну да, ОСи, браузеры, достаточно серьёзно?

Ну да, ОСи, браузеры, достаточно серьёзно?

драйвера для ОСи не являются примером динамической диспетчеризации?

у нас же там в памяти будет почти что vtable

драйвера для ОСи не являются примером динамической диспетчеризации?

Являются. Как и vfs. Тащем-то и всё.

Тот самый 1%

ну то есть балуются ж в C++ абстрактными виртуальными классами или всякими интерфейсами в java

Что?

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

Да, так лучше

Тот самый 1%

сильно сомневаюсь что это 1% ценности

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

Пля

))

Где я сказал, что она не нужна?

Где я сказал, что она не нужна?

не говорил, ладно)

но ты говоришь что "она нужна редко", и я согласен. Но это именно то что позволяет вырастить гибкую систему

и даже если это редко - 1% в 90% проектов

Просто где-то она идиоматична, а где-то нет. Вот взять к примеру кресты — каждый объект будет иметь ссылки на vtable (несколько, если множественное наследование) + сами данные, посколько полиморфизм подтипов во все поля. Если же взять раст, то там для динамической диспетчеризации используется trait object-ы и это не ссылка на vtable+даннные, а отдельно ссылка на vtable и ссылка на данные, чтобы не платить за лишние 8 байт. Просто потому что идиоматично использовать статическую диспетчеризацию

то это 90% проектов

Ладно, я не знаю о чём мы говорим уже

да я тоже, но последняя инфа по rust мне кажется полезной, почитаю

Полиморфизм подтипов легко меняется на типажи/интерфейсы и получаешь возможность использовать статическую диспетчеризацию.

Единственный кейс для динамики остаётся только в создании колекции над разными объектами одного интерфейса

Это те самые драйвера (выбор среди списка драйверов), vfs (среди списка ФС)

Вот тут да, никак не обойтись без динамики

Полиморфизм подтипов легко меняется на типажи/интерфейсы и получаешь возможность использовать статическую диспетчеризацию.

немного тупой вопрос, не означает ли это отсутствие late binding?

да я тоже, но последняя инфа по rust мне кажется полезной, почитаю

http://alschwalm.com/blog/static/2017/03/07/exploring-dynamic-dispatch-in-rust/

Спасибо

немного тупой вопрос, не означает ли это отсутствие late binding?

Если vtable создаётся в компайлтайме, то late binding нет

Ибо для каждой виртуальной функции уже должен быть слот в ней

ну теперь буду пережевывать информацию так ли нужен late binding...

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

(не smalltalk/erlang)

https://www.youtube.com/watch?v=YKXfOYTBaI4

Привет бандиты, у меня тут вопрос в ТЗ специально прям как для вас)

Какая идеологическая разница между интерфейсом с трейтами в сравнении с абстрактным классом?

в php?

интерфейс с трейтами это то, что в пыхе

или то, за что @ployd топит?)

в php?

Ну вопрос сам по себе

Но чаще пыха подразцмеваетсч

Вот я помню у вас дискуссия была

в пыхе трейты не подразумевают интерфейс

трейт не привязан к типу

трейт - исключительно про реализацию

абстрактный класс - про контракт и частичную реализацию

короче в типах дело

в контрактах

отвечая на вопрос в рамках пыха, если интерфейс описывает то же поведение, что и абстрактный класс, комбинацией трейты+интерфейсы можно описать несколько поведений в одном объекте, а наследованием от абстрактного класса - нельзя.

это адмен phpgeeks)

который оценил себя в своем резюме в 140к рублей

это сарказм?

админ != эксперт

или я не понял, о чем ты

админ != эксперт

"админ" тут скорее как идентификатор я использовал

не суть важно

который оценил себя в своем резюме в 140к рублей

Что всех так коробит моя самооценка))

ERROR: S client not available

оверпрайснута

да и ладно, почему нет?

ммм. не тот чатик

Отож

Отступы 2 пробела – 25 ??????? 42% 4 пробела – 17 ????? 29% Таб – 16 ???? 27% 3 пробела ?! – 1 ▫️ 2% ? 59 people voted so far.

а еще можно без отступов )))

https://image.slidesharecdn.com/slides-150227073035-conversion-gate02/95/how-to-use-selenium-successfully-java-edition-10-638.jpg?cb=1425043961

Отступы 2 пробела – 25 ??????? 42% 4 пробела – 17 ????? 29% Таб – 16 ???? 27% 3 пробела ?! – 1 ▫️ 2% ? 59 people voted so far.

почему нет варианта "по ситуации" или просто "пофигу"?

День добрый. Подскажите, кто-нибудь использует UML в реальной работе, рисует там овердофига диаграм со связями и тд? Или это только в кровавом энтерпрайзе?

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

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

ну то есть если ты ищешь поводов не знакомиться с UML - то не, с ним стоит познакомиться

тут как бы все просто. Если ты знаешь UML ты так или иначе найдешь ему полезное применение. Ну а если нет - не найдешь)

я к тому, что в универе щас пытаются заставить вызубрить все нотации, UML, DFD и тд, пытаюсь понять, потеря времени это или нет. Для себя гораздо проще на бумажке что-то абстрактное нарисовать и от этого отталкиваться.

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

С UML я конечно же пришлось познакомится, но каждый раз забываю, в какую сторону там треугольник должен быть повернут при наследовании, запомнить как там композиция\агреггация обозначается - лично для меня боль.

но разобраться надо)

Если это в реальности где-то еще используется, то конечно надо, да, потому тут в чатике у опытных товарищей и спрашиваю)

С UML я конечно же пришлось познакомится, но каждый раз забываю, в какую сторону там треугольник должен быть повернут при наследовании, запомнить как там композиция\агреггация обозначается - лично для меня боль.

ну направления стрелочек запомнить в целом не проблема. Попробуй закономерности найти. Например "наследование в ту сторону потому что зависит от той фигни а стрелочка такая-то потому что зависимости в форме наследования"

так попроще будет запомнить это все ну и в целом потом штуки вроде "инверсии зависимостей" будут восприниматься как само собой разумеющаяся штука

а вот например как прописываются асинхронные действия или там как правильно описать рекурсивные операции я и сейчас хз

обычно гуглю

ну то есть тебе больше надо уметь читать UML нежели писать)

писать ты можешь всегда нужные штуки загуглить

а вот например как прописываются асинхронные действия или там как правильно описать рекурсивные операции я и сейчас хз

Это все в суровом энтерпрайзе у вас нужно?)

писать ты можешь всегда нужные штуки загуглить

Понятное дело. Но если диаграмма классов помогает лучше понять архитектуру, почему тогда в доках каких-нибудь либ ее обычно нет

Потому что не помогает, лол

Понятное дело. Но если диаграмма классов помогает лучше понять архитектуру, почему тогда в доках каких-нибудь либ ее обычно нет

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

ее иногда просят

Диаграмма компонентов, DFD, диаграмма последовательности — вот эти помогают