Языку программирования Rust исполнилось 10 лет

али вы постулируете что для всякого множества 4 вершин вас интересует выпуклое на них

постулируем, что порядок обхода задан порядком значений в конструкторе.

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

Ну так чего делать с унаследованным от прямоугольника методом set_dimensions(a, b)?

Зависит от задачи, как вариант – перекрыть и проверять на равенство a и b, если не выполняется – выбрасывать исключение. А вообще, если такие проблемы возникают, значит, иерархия классов построена неправильно.

Никогда не был в секте почитателей Торвальдса. Более того даже не считал его супер умным или талантиливым. Просто он успел попасть в удачно в нишу и встать под GPL - все его заслуги.

Нет, это не его заслуга. Его заслуга в том, что он является бессменным лидером проекта одного из самых успешных ядер в мире (говоря политкорректно) уже 35 лет. Это огромный промежуток времени. И на везении 35 лет не продержишься. Заменят или форкнут. Это Стив Джобс из мира IT.

Добавлю, что есть ещё git. Который де-факто победил все остальные системы контроля версий. Т.е. Линус не одним ядром знаменит.

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

Эта проблема решается легко - используя иммутабельные объекты. Когда говорят «любой квадрат это прямоугольник», неявно подразумевают «любой квадрат с неизменяемыми сторонами это прямоугольник с неизменяемыми сторонами».

А если очень хочется - можешь в квадрате переопределить set_dimensions и кидать исключение, если валидация не прошла.

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

если их несколько - значит сама система классов в данном месте построена неверно.

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

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

Имхо это тот самый случай, когда нельзя, но если очень хочется, то можно )) В конце концов, мы здесь вынуждены оперировать тем, что излагает unC0Rr… Соглашусь, скорее всего его (умозрительную) иерархию классов надо бы переделать.

Соглашусь, скорее всего его (умозрительную) иерархию классов надо бы переделать.

То, что он предлагает, называется folktaxonomy. Oт слова - народная, или - как почудилось, такая и классификация.

один из примеров которой

Животные подразделяются на: 
а) принадлежащих императору; 
б) бальзамированных; 
в) прирученных; 
г) молодых поросят; 
д) сирен; 
е) сказочных; 
ж) бродячих собак; 
з) заключенных в настоящую классификацию; 
и) буйствующих, как в безумии; 
к) неисчислимых; 
л) нарисованных очень тонкой кисточкой на верблюжьей шерсти; 
м) и прочих; 
н) только что разбивших кувшин; 
о) издалека кажущихся мухами». 

Ты не поверишь, сколько заказчиков включают в ТЗ именно такую таксономию… ;)

Ну так чего делать с унаследованным от прямоугольника методом

Забить на запартные размышления и пользоваться наследованием по назначению. А именно: берешь фреймворк с кучей готовых классов, просто наследуешься от них и добавляешь щепотку своего кода, сдаёшь работу, получаешь зряплату и идёшь бухать. Всё это можно и на делегации сделать, но там будет «ехал wrapper через wrapper» с ручной работой и с теми же проблемами, что и при наследовании. Не говоря о том, что фреймоворков без наследования как-то не наблюдается. А на модных язычках без ООП вообще нихрена не наблюдается и предлагается каждому устраивать праздник велосипедостроения.

Это Стив Джобс из мира IT.

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

Вот такая сборная солянка. Бардак? Да. Но ты можешь выработать свою методику работы и делать все, что тебе нужно.

Это существенно замедляет изучение языка. Не проще ли взять PHP - тоже скриптовый и тоже Си-образный?
Хотя как «клей» для unix утилит подходит хуже, чем Perl..

Хотя как «клей» для unix утилит подходит хуже, чем Perl..

Для этих целей я использую bash. если что то более серьезное, то использую python

просто «для информации», количество исходников для сборки:
cargo-c -> 335
rustup -> 383

Пока диды пишут на Си - проблем с памятью им не видать))))) А если что, то просто маллоки() и фри() перепроверить нужно еще раз))))