Хм Ща меня (в роле Лоханкина ) наверно будут сильно бить, но у меня опять осеннее обострение, извиняйте и если чего, то это скорее всего отправится в юмор, но пока злые черти побермудят воду во пруду...

Закралась давным-давно у меня навязчивая идея, не решался огласить вслух всем, ибо стыдно(хотя совести у меня нет) за обострение! Может её бессмысленности уже сто лет, но на то я и... что бы увидеть в ней брешь неизученности Причиной произошедшего явилось то, что начитался тут судьбоносных тем по поводу ФП/АОП, статичиской и динамической типизации, ИИ, нейросистем, управляемого термояда, вопросов применения Ur-235 и Co-60 в домашних условиях и даже попытки создания R#, а про генетику, акромя скромных потуг на клонирование, ничего не звучало, хотя это и есть, как мне кажется неприкрытый пуп Земли После чего наверно я окончательно рассеялся как обычно

Скажите мне правду!
Может были некоторые задумки/исследования или уже где-то применяется ... генно-ориентированное программирование или что-то подобное?
Ой, может я перебощил, может это все-таки того не стоит называть...
Интересует конечно не библиотеки, сборки и даже не пространства имен генетической направленности (хотя это тоже интересно), а простая на мой взгляд, хотя может и бредовая по-сути /прошу мне на это указать как можно деликатнее / идея написания программ в такой среде разработки с языковыми средствами, которая могла бы самостоятельно понимать как совмещать (не знаю, как правильно и назвать то это, может — абсорбировать /агрегировать/конкатенировать или ещё как...) классы по общим признакам доминирующих и рецессивных (подавленных) полей виртуальных методов их одноименных полей одинаковой сигнатуры в некий суб-класс (от слова "субъект") на этапе разработки и при множественно-сборочной компиляции (т.е. в рамках компонентной модели). Реализации чего-то сродни принцыпу генетических механизмов подавления признаков. При этом мне кажется уместно было бы предусмотреть методы-агенты для "совмещения несовместимого" кода методов при замене доминирующими методами рецессивных (наподобии специализаций в дженериках), а так же какие-то правила (наподобии области видимости кого с кем вообще можно совмещать,а кого нет ), а может быть нужны и сложные механизмы приоритетов при отборе доминирования. Нужно понимание о прозрачных и простых правилах и конструктивных средствах употребления всего этого вместе с ООП и ИЯ. Например, просто создавая объект какого-то класса, компилятор сам понимал какой цепочкой классов (доминирующего и набора рецессивных ему) надо воспользоваться и проч. Интересны общие правила автоматической компановки цепочек по признаку этого всего, что бы можно было понять это не только на интуитивном уровне. Если об этом что-то было, то мне думается что обязательно как-то должно укладываться в компонентную модель.
Прошу так же заметить, что кажется это не лежит в плоскости вопросов о множественном наследовании, и тем более дженериков/шаблонов, скорее наверно наоборот, должно решать им ортогональную задачу. Кажется, что необходимость в этом только при совмещении классов, не имеющих общих предков, т.е. описывающих разные, но имеющие некоторое соприкосновение предметные области классов, ну или только на уровне общего базового класса.

И ещё... вот это уже может быть и совсем не к месту... органические и неорганические классы
Т.е. идея в том, что органические классы не могут иметь конструкторы/деструкторы, а их роль — быть вспмогательными к органическим и совмещаться с ними при создании такой агрегации, или может это называется вирусами?