Ни о какой безапелляционности в моих высказываниях не может быть и речи!

mixinы - это интерфейсы, но они могут содержать код. Чего очень часто не хватает: что-то вроде:

mixin Ordreded {
abstract int compareTo (Object o);
boolean equal (Object o) { return compareTo (o) == 0; }
}

From:

Все равно непонятно. Чем это отличается от абстрактного класса, который может содержать методы с кодом, а может и без кода?

From:

faceted-jacinth.livejournal.com

1. Ну так давно же (подозреваю, что очень давно) ходит по сети текстик "от создателей языка С" про то, что это всё было первоапрельской шуткой.

2. В интерфейсе кода нет. А в микс-ине есть. Ну вот например представьте, что вы хотите добавить классу (и не одному!) метод ToString() (а раньше его не было). На каком-нибудь шарпе (до третьего) получается изрядный геморрой: пишется класс ToStringHelper, в котором реализуется всё, плюс интерфейс IToString, а затем от каждого класса делается наследование и пишутся одни и те же перенаправления из методов интерфейса в методы ToStringHelper. А то и вдобавок создание инкапсулированного объекта ToStringHelper со своим конструктором.

Если посмотреть внимательно, то это то же самое множественное наследование, только реализованное ручками.

From:

andrzejn

По-моему, в википедии сказано вполне внятно. Mixin - это почти то же масое, что и интерфейс, но может содержать не только объявления методов, но и их реализацию. Класс может унаследоваться от нескольких mixin'ов и сразу получить в своё распоряжение базовые реализации всех интерфейсных методов. От обычного множественного наследования это отличается, скорее, идеологически, чем по сути: при множественном наследовании базовые классы обычно представляют и самостоятельную ценность, а mixin сам по себе смысла не имеет, как не имеет самостоятельной ценности отдельно взятый интерфейс.

From:

andrzejn

Отличается только идеологически, чтобы подчеркнуть фрагментарность и односторонность предназначения mixin'а. Практически это и есть абстрактный класс.

From:

ойой.

вобщем существенно более интересный язык получается когда объекты рассматриваются как _набор_ методов и data members.

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

насчет C++ -- я тоже надеюсь, чтоони когданить признаются что это была ошибка :)

From:

lnvp.livejournal.com

А чего ему каяться-то, когда такой расклад попёр? Кому каяться, по моему мнению, так это Вирту. Были козыри у профессора, и ни один не сыграл.

From:

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

Интерфейс-же - констукция не идеологическая, а именно реализационная - для честного множественного наследования хорошей сематники без криви никто так и не придумал (см радости С++)

From:

Да, но абстрактный класс тоже неспособен к самостоятельному существованию.

From:

Эх, вот вы говорите слова, но из них не складывается картинка :)

Давайте более дотошно. Объект - набор методов и data members, отлично, я могу таким образом на объект посмотреть и в C++, и в Java (которые не заявляют, что поддерживают миксины). Что такое "сложение интерфейсов" - то же, что в C++ наследование от двух классов, а в Java реализация двух интерфейсов? А что такое вычитание или пересечение, на практике? И какая интересная идеология появляется?

From:

data members тоже в принципе не нужны. В принципе тогда вообще отпадает надобность в большитсве этих понятий. Довольно хороший пример - O'Caml - там объект - просто набор методов (язык функциональный, поэтому "data members" фактически просто спрятанные в класс переменные, которые доступны методам).

Тип объекта - просто список методов с их типами. Вместо наследования есть отношение тип/подтип над типами объектов - по наличию и совместимости методов.

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

Самое интересное - что язык статически типизированный и нет никакого аналога rtti.

From:

andrzejn

А как насчёт множественного наследования в Eiffel? С переименованиями конфликтующих методов, с изменениями параметров видимости...

From:

Не совсем - у него есть конструкторы, поля данных и т.п. То есть - он ведет себя как обычный класс, единственное ограничение - на него new нельзя написать.

При множественном наследовании с определением семантики для всего этого дела возникают проблемы - стандартная - класс является общим предком двух других, их потом скрещивают путем наследования. Что там делать с вызовом конструктора для общего предка etc. В С++ криви на этой почве изрядно и ничего особенно удобного так и не придумали.

А интерфейс и mixin - это просто куски vmt и все. У mixin'а просто некоторые поля уже заполнены.

From:

Так примерно также. Выкрутиться-то можно - в С++ тоже проблемы решены. Просто довольно громоздко получается. Самый, пожалуй забавынй вариант в O'Caml, но там пришлось отказаться от понятия наследования в нормальном виде. И downcasting невозможен в принципе.

From:

michanium.livejournal.com

Кстати, Вирта я видел в живую. На вопросы по С++ он отвечал политкорректно.
По воводу C#: его корни как раз ведут в его университет.

From:

Непонятно, зачем нужно новое слово, в чем именно его идеологическая составляющая.

Давайте попробуем методически.

В C++ есть abstract base class. У него есть методы без кода, но могут быть и методы с кодом тоже. От него невозможно создать объект. Ему можно наследовать. Самостоятельной ценности он не имеет.

В Java есть abstract class. У него есть методы без кода, но могут быть и методы с кодом тоже. От него невозможно создать объект. От него можно наследовать, но не множественно. Самостоятельной ценности он не имеет.

В Java есть также интерфейс. У него есть только методы без кода. От него невозможно создать объект. От него можно наследовать, в том числе и множественно. Самостоятельной ценности он не имеет.

Если я правильно вас понял, вы говорите следующее: миксин является полным аналогом abstract base class в C++, и не является полным аналогом abstract class в Java, поскольку миксины можно смешивать в множественном наследовании, а абстрактные классы в Джаве нельзя. Таким образом (я продолжаю свою попытку пересказать ваше мнение), понятия миксина опирается на мнение, что попытка Джавы "укротить" множественное наследование C++ путем ограничения его только на интерфейсы была слишком жесткой, и следует ее "откатить", вернувшись к неограниченному множественному наследованию C++, но на практике применяя его только к абстрактным классам, и называть их миксинами.

Я правильно понял?

From:

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

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

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

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

From:

воот .

Я все-таки склоняюсь к тому, что OCaml придется выучить. для расширения кругозора.

From:

nine_k

Куда большие возможности в этой области даёт python ;) И, что удивительно, javascript.

From:

nine_k

Не, зачем стреляться? Надо искупать, без продыху разрабатывая новое и хорошее ;)

From:

насчет javacsript - да, на удивление интересный язык получился :) по сравнению с тем, что было 5-6 лет назад ;)

From:

andrzejn

По-моему, так.

From:

gianthare.livejournal.com

А что Страуструп, это же не он сделал C++ industry standard.

From: