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

дотнетчики не слышали что "унаследован значит является"?

так а чем тут поможет одиночное наследование (A -> B -> C)?

Это сообщение отредактировал(а) k0rvin - 15.6.2011, 19:53

в нем такая противоречивая ситуация невозможна в принципе.

Что значит никуда не годится рантайм, что под этим подразумеваете? 
А на счет сериализации зря вы так думаете, хотя я в делфи практически не сталкивался с надобностью сериализации, но вроде как если имеем TPersistant и TComponent то проблем нет, плюс есть  DBXJSONReflect или TJvAppXMLFileStorage. Я думаю есть, кто на счет этого может больше сказать. Что касаться .NET, ну да, там более красиво это сделано, возможности атрибутов плюс продуманные готовые интерфейсы делают сериализацию проще и непринужденнее,  но вот со сложными типами тоже можно намучаться(что называется плавали, знаем). Хотя вот даже просто возможность скопировать поток в поток появилась только  в 4 фреймворке.

так, еще раз

как одиночное наследование поможет вызвать метод, объявленный в A?

k0rvin, или это я плохо объясняю, или не знаю даже...

В классе А объявлен виртуальный метод. Он или публичный, или вызывается из какого-то публичного метода. Он наследуется всеми потомками и может быть вызван как метод потомка - прямо если публичный или косвенно, если нет. Унаследуем от А классы В1 и В2, в каждом из которых метод перекрыт по своему. Можно вызывать B1.Method() или B2.Method() и получить разное поведение. 

При наличии множественного наследования, возможно унаследовать класс С от двух родителей B1 и B2. Поскольку А является предком С, то имея экземпляр С можно вызвать наш метод. Противоречие заключается в том, что не понятно какая реализация должна быть вызвана: из В1 или из В2  

При отсутствии множественного наследования С наследуется или от В1 или от В2, но не от обоих сразу, поэтому противоречия не возникает.

и компилятор укажет на это противоречие и потребует от программиста явно указать какой из методов должен использоваться в C. так в C++. так в Delphi при реализации классом двух интерфейсов с одинаковыми методами. а в CLOS, например, используется precedence-list, т.е. по-умолчанию в данном случае будет использоваться B1

Из вики я узнал что это называется проблемой ромба)) 
Вообще вот список проблем множественного наследования, из вики:

• семантическая неопределенность часто совокупно представляется как Проблема ромба.
• отсутствует возможность явного многократного наследования от одного класса
• порядок наследования изменяет семантику класса
• Множественное наследование в языках с конструкторами в стиле C++/Java усиливает проблему наследования конструкторов и последовательностей конструкторов, таким образом создавая проблемы с поддержкой и расширяемостью в этих языках. Объекты в отношениях наследования со значительно отличающимися методами конструирования довольно трудны для реализации в рамках парадигмы последовательности конструкторов.

И правильно в сад его, слишком много неопределенностей вносит

Тут холивар, а вы теории обсуждаете =)

как хорошо, что CLOS лишена этих проблем =)

да нафиг нужно это множественное наследование

Затем чтобы удобнее делать некоторые вещи, как с интерфейсами в Делфи.

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

Добавлено через 26 секунд
ну конечно... это уже ведь не забота программиста )))

Akella, это такой вброс сейчас был? =)
Если есть инет, размер установщика крайне мал (меньше Мб), если же обычный - 48 Мб.
Я это все к тому, что не так уж и много ;)