написано, что встроено в язык - https://en.wikipedia.org/wiki/Multiple_dispatch#C#

через dynamic

Если скинете пример использования на ванильной версии, я бы посмотрел. Не смог найти к сожалению

по моей ссылке не оно?

Ещё на ум приходят проблемы с девиртуализацией. У меня даже double dispatch при неосторожном использовании вызывал дикие посадки производительности, а уж как тут будет не понятно

Да, с телефона смотрел, не все плашки раскрыл

ага, согласен - для повсеместного использования этого происзодительность важна

Хм, ну в целом ещё вопросы к тому как это будет работать с параметрическими типами. И расширяемость чужого кода тоже надо смотреть

То есть наверное можно сделать и то, и то, но сколько усилий на это нужно тратить?

видимо в этом и дело...

Я представляю прям реакцию моего ИТ, если я предложу переписать квантлиб на это)

а про MD в питоне, о чём тут писали выше - с одной стороны, формально его можно реализовать, есть адекватные библиотеки для этого
но большинство используемых пакетов написано по факту на C на нижнем уровне, поэтому даже свой тип в numpy-массив нормально не впихнуть

и какие-нибудь "массивы чисел с +- ошибками" приходится реализовывать отдельно

недостаточно иметь отдельно "массив" и отдельно "число с +- ошибкой"

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

В общем, я тут подумал, и мне кажется, что на эту проблему (OOP vs MD vs FP) можно смотреть с очень разных точек зрения и за счёт этого видеть разные проблемы или не видеть проблему вообще.

То, что обсуждается в том топике в дискурсе, это скорее всего про будни кор разработчиков. Сама по себе expression problem не является смертельной и разумеется она решабельна иначе у нас уже не было бы ни OOP ни каких-либо других языков программирования.

Наверное основным следствием этой проблемы является то, что её наличие значительно усложняет разработку и поддержку библиотек. Одно дело, когда тебе надо быстро что-то где-то подлатать - тут достаточно бесполезно спорить о том, что лучше, mulitple dispatch, mixin, extensions или что там ещё люди придумали. Другой вопрос, если ты разработчик, который сидит перед пустым экраном и готовится писать код, который теоретически должен будет использоваться сотнями других разработчиков на протяжении многих лет, и при этом будущая библиотека должна быть не просто используемой, но и легко расширяемой другими людьми.

В этом случае стоимость архитектурной ошибки возрастает чудовищно, так как любой рефакторинг это очень и очень болезненная процедура. Так вот, дискуссию о разных подходах я бы наверное рассматривал именно с этой позиции. Невозможно заглянуть в будущее и угадать, что именно и как именно будет использоваться, поэтому в OOP подходе очень легко ошибиться архитектурно - выбрать неправильную иерархию типов или где-то ещё просчитаться. Да, разные OOP языки предлагают определённые формы которые позволяют нивелировать такие ошибки до какой-то степени (тот же самый monkey patching), но это обычно воспринимается как латание дыр и в какой-то момент всё равно приходится производить существенный рефакторинг.

Вроде как в противоположность этому multiple dispatch гораздо менее требователен к прототипированию библиотеки и с его использованием сложнее ошибиться. Если ты написал функцию foo(bar, baz) то она будет работать для любых объектов bar и baz до тех пор пока они удовлетворяют какому-то набору условий нужному для работы функции. То есть потенциально твой код будет адекватно работать даже для библиотек, которые ещё не существуют в природе.

Вот как-то так. Предлагается сравнивать не текущие сиюминутные различия между подходами, а стоимость разработки/поддержки в long term с учётом рефакторингов. Разумеется эта оценка я думаю сейчас чисто эмпирическая, те кто руку набил на разработке сложных OOP проектов скажут (и скорее всего справедливо), что они могут с нуля написать библиотеку, которую не нужно будет переделывать и перевес будет в сторону OOP. Кто-то другой скажет, что он устал постоянно переделывать свои OOP библиотеки, а переход на MD позволил ему вообще не заботиться о такого сорта поддержке и рефакторинги стали быстрыми и декоративными.

Я могу сказать про свой личный опыт. У меня как раз expression problem проявляет себя во всей красе при повседневном написании кода, и он далеко не библиотечный

И ещё и при использовании готовых библиотек, которые уже годами разрабатываются. Проблема даже не в том, что в архитектуре ошиблись, а в том, что с single dispatch не всегда можно сделать нормальную архитектуру, в любом случае получится монстр

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

Привет всем

Привет!