ОСь целиком написанная на .Net (в основном C#) не может не тормозить по определению. Уже сейчас Виста кряхтит от относительно небольшого кол-ва управляемого ООП кода, а Windows 7 нужно 4 Гб оперативы. Что будет в Сингулярности?

> Не вырывай цитату из контекста

Да упаси ТНБ. Я увидел непонятную фразу и решил прояснить.

> если в MOP гарантируется, что это замыкание сломать нельзя, то в смоллтоке -- не гарантируется

Фраза "сломать замыкание" тоже непонятна :)

Смейся, смейся. GObject умеет больше, чем С++.

>>> Если хочешь сделать так - можно

ну значит, нельзя -- если вас интересует результат? :))

> Только вот непонятно, причем к динамическому наследованию экземпляров, отрицающему механизм множественного наследования, принципиально статический механизм выведения типов.

ну возвращаясь к множественному наследованию и нужно ли оно. Множественное наследование интерфейсов и поведения -- нужно, множественное наследование экземпляров -- нужно не всегда (если экземпляры из одного "однородного набора", не нужно, если из разного -- может быть). То есть, нужно задать интерфейс паттерна, когда оно нужно, когда не нужно. Если наследовать в динамике, то можно повторить и "множественное наследование", когда нужно, и ещё что-то, чего множественным наследованием классов не сделать. А статистический механизм вывода типов -- для задания "однородного набора", интерфейса, когда этот конкретный набор можно вместе "наследовать в экземпляре в рантайме", а когда нельзя.

>> Если хочешь сделать так - можно

>ну значит, нельзя -- если вас интересует результат? :))

Если интересует результат - так делать не следует.

> Множественное наследование интерфейсов и поведения -- нужно, множественное наследование экземпляров -- нужно не всегда (если экземпляры из одного "однородного набора", не нужно, если из разного -- может быть). То есть, нужно задать интерфейс паттерна, когда оно нужно, когда не нужно. Если наследовать в динамике, то можно повторить и "множественное наследование", когда нужно, и ещё что-то, чего множественным наследованием классов не сделать. А статистический механизм вывода типов -- для задания "однородного набора", интерфейса, когда этот конкретный набор можно вместе "наследовать в экземпляре в рантайме", а когда нельзя.

Parsing error, bailing out.

> Смейся, смейся. GObject умеет больше, чем С++.

Ага. Мой папа сильнее твоего папы! Патамуся мой папа -- милисианей! :)

Ну и разговор тут у вас... Профессиональный. Не буду мешать...

>ну возвращаясь к множественному наследованию и нужно ли оно. Множественное наследование интерфейсов и поведения -- нужно, множественное наследование экземпляров -- нужно не всегда (если экземпляры из одного "однородного набора", не нужно, если из разного -- может быть). То есть, нужно задать интерфейс паттерна, когда оно нужно, когда не нужно. Если наследовать в динамике, то можно повторить и "множественное наследование", когда нужно, и ещё что-то, чего множественным наследованием классов не сделать. А статистический механизм вывода типов -- для задания "однородного набора", интерфейса, когда этот конкретный набор можно вместе "наследовать в экземпляре в рантайме", а когда нельзя.

Здравствуй, Гегель.

Понеслась...

> ОСь целиком написанная на .Net (в основном C#) не может не тормозить по определению.

Гм. .Net - вещь универсальная, там может быть и не ООП. А шарпа я не знаю.

fixed

s/статистический /статический/

Во первых, он навязывает как минимум свой ООП. А если тебе нужен другой ООП, нормальный, то изволь писать костыль.

Единственная нормальная виртуальная машина - LLVM. Она низкоуровневая, и по этому быстрая и гибкая, не лишая нас при этом ни переносимости, ни JIT, ни массы др. фич.

Google жжет: хочу прочитать про CLR, пишу запрос "CIL Net", а он мне "Возможно, вы имели в виду: СИЛ Нет"

1. чем отличается множественное наследование классов и агрегирование классов?

2. когда реально нужно множественное наследование, в каких ситуациях. Нужно ли тут наследование классов в статике или экземпляров объектов в динамике.

3. Если множественное наследование когда-то нужно (например, в шаблонах в ATL, WTL) -- значит, есть интерфейс паттерна, каким образом оно используется?

4. Если интерфейс можно задать через шаблоны, значит, его можно задать статически выводимой системой типов?

> Google жжет: хочу прочитать про CLR, пишу запрос "CIL Net", а он мне "Возможно, вы имели в виду: СИЛ Нет"

Ты знаешь, он в чем-то прав. Удовлетворить запрос человека, у которого свой нормальный ООП, нормальная виртуальная машина, которая гибкая и BSD, который из-за Каноникла уже GPL, -- сил у даже у искусственного интеллекта не хватит...

> динамическому наследованию экземпляров, отрицающему механизм множественного наследования

с этим не согласен. Оно не отрицает, а расширяет этот механизм, от наследования классов -- к наследованию экземпляров.

> машина является стековой, причем стек является статически типизированным; это означает, что в каждой точке программы JIT-compiler должен иметь возможность статически определить типы содержимого всех ячеек стека. На практике это означает, например, невозможность написать код, кладущий в цикле значения на стек

> машина является объектно-ориентированной: структура MSIL отражает разбиение кода на классы, методы и т.п.

Так что ты не прав: во-первых ограничение на то, что машина - стековая, во-вторых-таки обязательное ООП. Плюс навязанная статическая типизация (Python, Perl, Smalltalk в пролете). И стандартная библиотека, заточенная именно под C#. Я даже не представляю, как из Си под .Net обращаться к этим классам.

> во-первых ограничение на то, что машина - стековая

И чем это ограничение принципиально?

> Плюс навязанная статическая типизация (Python, Perl, Smalltalk в пролете)

Python и Smalltalk реализованы.

> стандартная библиотека, заточенная именно под C#

Тем не менее ее используют все языки платформы. И практически любой современный язык имеет ООП-подмножество.

>Python и Smalltalk реализованы.

Можно и трактор из дерева реализовать. Я видел JavaVM, написанную на JavaScript.

>> во-первых ограничение на то, что машина - стековая

>И чем это ограничение принципиально?

А она точно стековая? У меня такое ощущение, что xTERM что-то перепутал. Стековая машина имеет место в JVM, и где-то на ЛОР-е я читал что Гослинг считает это своей ошибкой, поскольку со стековым кодом есть какие-то проблемы.

> Во первых, он навязывает как минимум свой ООП. А если тебе нужен другой ООП, нормальный, то изволь писать костыль.

Батенька, да вы в показаниях запутались. Мы же, вроде, договорились, что нам ООП не нужен?

> 1. чем отличается множественное наследование классов и агрегирование классов?

Тем же, что и одиночное наследование от агрегирования - т.е., кучей вещей, о которых я не знаю, и нарушением LSP.

> 2. когда реально нужно множественное наследование, в каких ситуациях.

Что значит "нужно"? Если "необходимо", то таких ситуаций просто нет, всегда можно обойтись одиночным наследованием и методов asSomethingElse. Более того, можно обойтись и без одиночного наследования. Если "нужно" значит "выгодно", то это случаи, когда объединяются 2 иерархии.

> Нужно ли тут наследование классов в статике или экземпляров объектов в динамике.

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

Насчет остального - parsing error.

> Можно и трактор из дерева реализовать.

Какие тебе ещё аргументы нужны? Есть реализации схемы для .net-а, там ни статики, ни ООП, классическое функциональное программирование. С тобой же невозможно дискутировать, ты на все аргументы находишь гнилые отмазки вроде деревянных тракторов. Сколько времени ты практически работал с виртуальными машинами — создавал свои, может писал компиляторы в байткод, может писал JIT-компиляторы. Ты производишь впечатление человека, нахватавшегося вершков и пытающегося этими вершками оперировать, а когда знаний не хватает, апеллировать к идиотским аналогиям.

> Так что ты не прав: во-первых ограничение на то, что машина - стековая, во-вторых-таки обязательное ООП.

Да шо ты такое говоришь? А как же в него Haskell или Lisp компилят?

> Я даже не представляю, как из Си под .Net обращаться к этим классам.

А вот ребята, делающие lcc - представляют. Правда, накуя это нужно - не представляю уже я.

> А она точно стековая?

Да.

> Стековая машина имеет место в JVM

Она много где используется. У Perl5 стековая машина, ЕМНИП.

> со стековым кодом есть какие-то проблемы.

Stack-based vs register-baseed - это древний холивор :)

>Мы же, вроде, договорились, что нам ООП не нужен?

Тогда зачем вам .Net, если ООП не нужен?

> Можно и трактор из дерева реализовать.

А в огороде растет бузина.

>Какие тебе ещё аргументы нужны? Есть реализации схемы для .net-а, там ни статики, ни ООП, классическое функциональное программирование.

Вы бы сами сначала удосужились ознакомиться с предметом. Посмотрите бенчмарки IronPython http://shootout.alioth.debian.org/gp4sandbox/benchmark.php?test=all&lang=... и поймете, почему он "деревянный"

> Тогда зачем вам .Net, если ООП не нужен?

Ну, например, для облегчения интеграции разных языков. Или для кроссплатформенности (Mono, ага).

>Ну, например, для облегчения интеграции разных языков.

Давайте сначала выясним, какие структуры данных нужно интегрировать. Процедуры итак достаточно нормально интегрируются в компилируемых языках, а если ООП вам/нам не нужно, то что еще вам нужно интегрировать? Стандартную библиотеку? Простите, но у высокоуровневых языков она всегда своя. Даже Scala переопределяют многие стандартные классы. Это особенность языка.

>Или для кроссплатформенности (Mono, ага).

На чем написана Ява? Mono? На Си.

Аппаратная переносимость у gcc очень высокая, да и компилится Си и многие его либы почти везде.

У С# нет своей стандартной библиотеки. Есть одна библиотека - .NET.

У C# нет, а у многих есть. Просто С# - это самый интегрированный с .Net язык, с чего это у него была своя библиотека?

использование множественное наследование - это признак неправильно спланированной иерархии. В 100% случаев оно не нужно. Одно наследование реализации и множество интерфейсов - это каноническое правило. Отступать от него - это отступать от правил настоящего ООП, которые были заложены в Java.
Зы. Ц++ я (да и многие другие) вообще не считаю объектно-ориентированным язык.

> Одно наследование реализации и множество интерфейсов - это каноническое правило.

Афигеть. В ООП уже завелись каноны? Что дальше - святые появятся?

Множественное наследование (невиртуальное) и сигнатуры - вот труЪ-вэй. К сожалению, им не пошли.

> правил настоящего ООП, которые были заложены в Java

Круто. Не Симула67, не Смолток, LOOPS, CLOS, Objective-C, а именно Ява? И ты можешь это обосновать, конечно же?

> Ц++ я (да и многие другие) вообще не считаю объектно-ориентированным язык.

Да, это очень важно.

> использование множественное наследование - это признак неправильно спланированной иерархии. Одно наследование реализации и множество интерфейсов - это каноническое правило. Отступать от него - это отступать от правил настоящего ООП, которые были заложены в Java.

Была бы шляпа -- снял бы... (Жабку принимать за классику ООП!!?) ИМХО жабские интерфейсы практически ничем от множественного наследования не отличаются. То, что оно зло, согласен. Но и "правильное" "планирование иерархии" в ООП ИМХО утопия. Боле того, оно просто ошибочно, типа веры в то, что любое алгебраическое уравнение можно решить в радикалах: и не нужно, и не так.

> http://insidecpp.ru/art/8/

> Рассмотрим простой пример, иллюстрирующий неправильное использование наследования: базовый класс «Фигура» и его дочерние классы «Круг», «Квадрат» и «Треугольник». Такой подход в построении архитектуры является неправильным. Суть ошибки состоит в том, что в данном случае мы пытаемся отобразить концептуальные типы в языковые. Класс в C++ должен являться функциональной единицей, а не концептуальным типом. Функциональной единицей в приведенном примере является класс «Фигура». Ее конкретизация в круг, квадрат или треугольник не является новой функциональной единицей. Это всего лишь концептуальная конкретизация.

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

Т.е., я хочу сказать, за деревьями не видно леса, из-за этого.

>> Документация не для Ъ.

Это кто тебе такую глупость сказал?

>Батенька, да вы в показаниях запутались. Мы же, вроде, договорились, что нам ООП не нужен?

Это вы может и договорились. А лично я сказал, что ООП нужна, для узкого круга задач. И нужно нормальное ООП.

Для того, чтоб разбирать, откуда там что взялось, есть наглядное графическое представление - UML. А если писать как пьяный итальянский повар, то конечно хрен что разберёшь в спагетти.

C# - не самый интегрированный с .NET язык, многие возможности .NET из него не доступны.

> Тогда зачем вам .Net, если ООП не нужен?

В .net много чего вкусного есть кроме всех этих классов-шмассов.

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

Hint: UML. Надеюсь, бумагу и карандаш в детском саду проходили?

Есть. Но в том же LLVM есть тоже много вкусностей (классов там естественно нет). Так что зачем юзать заточенную под венду технологию, если есть наше, не хуже? От куда такие "патриоты" на ЛОРе?

Только не говорите, что .Net такая вся универсальная, не зависящая от ОС. MS сама говорит, что они создали VM, учитывающую специфику именно Windows.

> Да шо ты такое говоришь? А как же в него Haskell или Lisp компилят?

Через анальное отверстие.

>> Можно и трактор из дерева реализовать.

> А в огороде растет бузина.

На самом деле замечание по теме. Ибо в Iron Python уши .Net торчат настолько, что определить его как Питон можно только по вторичным половым признакам.

> В 100% случаев оно не нужно.

Мсье незнаком с миксинами?

/me вместе с tailgunner ожидает определения "не нужно"...

> Так что зачем юзать заточенную под венду технологию, если есть наше, не хуже?

Хуже. Объективно хуже. Ты красноглазый, тебе конечно же очень трудно понять, насколько важна интероперабельность со всем, что движется, доступность библиотек и развитая, высокопроизводительная VM.

Кроме того, LLVM - регистровая машина. Компилить под неё всё же несколько труднее чем под стековую. Ну да поскольку компиляторов ты не писал никогда, таких тонкостей ты тоже не понимаешь.

> Только не говорите, что .Net такая вся универсальная, не зависящая от ОС.

Давай ты мне указывать не будешь, что мне говорить, а что нет. Кто ты такой вообще? Правильно, ты - никто.

> MS сама говорит, что они создали VM, учитывающую специфику именно Windows.

Конкретно в VM ничего виндовс-специфичного нет. Да и в библиотеках тоже.

Нигани, глупец. Сам попробуй сначала разобраться в теме, а потом выступай, ок?

> Так что ты не прав: во-первых ограничение на то, что машина - стековая, во-вторых-таки обязательное ООП.

Это не ограничение, ламеришко.

Стековая она только на первый взгляд. Операций над стеком там не предусмотренно вообще, в отличии от JVM, так что стековое представление байткодов - это просто способ плоской записи AST. Восстановить дерево из байткодов IL можно тривиально и в один проход (то есть, очень быстро). А потом компилируй уже во что захочешь. С JVM этот номер не проходит в общем виде, сложно отслеживать положение объектов на стеке, с регистровыми же машинами вообще абзац, отображение одного набора регистров на другой - задача вычислительно крайне тяжелая.

А про "обязательное ООП" ты вообще чушь ляпнул абсолютно безграмотно.