программистское

[avva]

1. Читал недавно интервью с Струструпом про C++. В какой-то момент его там спрашивают: ну а вы не жалеете обо всем этом, не был ли дизайн C++ ошибкой? Он отвечает: нет, не жалею, не был итд. А я себе представил другой ответ: да; я давно хотел это сказать: простите меня. Меня мучила совесть все эти годы, и теперь я прошу всех программистов на C++: простите меня, я хотел как лучше. И стреляется. Было бы эффектнее!

2. Я не понимаю, что такое mixins. Не на уровне ключевых слов, а реальное понимание, что это такое и чем отличается ну там от интерфейсов и других ООП-механизмов. Википедия не помогает, там невнятно. Если кто-то может мне объяснить, буду признателен.

Comments

[kouzdra.livejournal.com]

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

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

[avva.livejournal.com]

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

[faceted-jacinth.livejournal.com]

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

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

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

[avva.livejournal.com]

Покажите простой пример использования миксина на шарпе (после третьего)?

[andrzejn]

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

[avva.livejournal.com]

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

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

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

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

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

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

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

[nm-work.livejournal.com]

ойой.

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

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

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

[avva.livejournal.com]

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

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

[lnvp.livejournal.com]

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

[michanium.livejournal.com]

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

[nine_k]

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

Пусть жираф был неправ, но виновен не жираф

[gianthare.livejournal.com]

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

[ex-matiouch.livejournal.com]

Не вспомню, где, и насколько это достоверно, но мне попадалось покаянное письмо, написанное Страуструпом, кажется, 1 апреля 1998 года, в котором он пишет ровно то, что Вы хотите: «Меня мучила совесть все эти годы, и теперь я прошу всех программистов на C++: простите меня, я хотел как лучше».

:-)

[http://users.livejournal.com/_zerg/]

нет, 1го апреля он писал про перегрузку пробела, только год вот не вспомню :)

[ltwood.livejournal.com]

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

Отдельное название используют, поскольку хотят подчеркнуть специфическую роль примеси как средства, реализующего некое побочное свойство класса, которое может иметь, а может и не иметь отношения к его основной функциональности. Например, по этой же причине используют термин Template Method, хотя это просто виртуальная функция.

[kouzdra.livejournal.com]

mixin, в котором все методы абстрактные - и есть интерфейс. Реализацией интерфейса (хотя бы частичной) он тоже может быть

template method - это не "просто виртуальная функция". Это полиморфная [виртуальная] функция. Также как template class - это параметризованный класс, а не просто класс.

[cmm.livejournal.com]

mixin как абстрактное понятие — это такой кирпичик с функциональностью, для использования при построении конкретных типов.

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

в языке с полным программатическим доступом к системе типов миксин может выглядеть, скажем, как функция, берущая класс A и возвращающая класс B, где B является A + добавочная функциональность.  подобная система, кстати, элегантно обходит проблемы со множественным наследованием — оно просто не нужно.

Self-modifying code rules!

[trurle.livejournal.com]

При мысли о сопровождении подобной программы мне становится зябко.

насчет застрелиться

[demoronizator.livejournal.com]

вроде для реально больших performance-bound проектов кроме c++ ничего и нет.

[vinopivets.livejournal.com]

Когда появился C, я прекратил писать программы, чуть позже я из перестал читать, а теперь, думаю, пора перестать ими пользоваться. Вот уж ровно тот случай, про который "Бывает, что усердие превозмогает и рассудок".

[gdy.livejournal.com]

Надо понимать, это ваш последний комментарий? ;-)

[madfire.livejournal.com]

http://www.rubycentral.com/book/tut_modules.html
Там довольно внятно написано зачем, по крайней мере с т.з. Руби.

Mix-ins in C++

[(Anonymous)]

Mix-ins in C++ (not sure about other languages, but I think mix-ins were first invented in C++?) is a class that implements some interface and is inherited by other classes for the sole purpose of re-using this implementation. The text-book example is reference counting:

struct RefCountable
{ 
  virtual void inc_ref () = 0;
  virtual void dec_ref () = 0;
};

struct Object: virtual RefCountable
{
  virtual void f () = 0;
};

Now we want to implemen Object but would like to use some existing implementation of the RefCountable interface:

struct AtomicOpRefCountable: virtual RefCountable
{
  // ... implementation goes here
};

struct MyObj: Object, AtomicOpRefCountable
{
  virtual void f ()
  {
    // ...
  }
};

Here we are mix'ing-in implementation of RefCountable provided by AtomicOpRefCountable.

hth

Mixins

[msh.livejournal.com]

Да ничего особенного, просто абстрактный класс, в котором есть имплементация. Кризис в CS, нового нет ничего, приходится старому новые названия выдумывать для видимости прогресса.

Наверное, если начинать с языка, где используют интерфейсы без имплементации и нет множественного наследования, mixins действительно выглядят чем-то необычным, а программист на на C++ их просто не замечает ;-)

Re: Mixins

[kouzdra.livejournal.com]

mixin'ы придумали лет 20-25 назад.

[gdy.livejournal.com]

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

[gdy.livejournal.com]

Хороший пример есть в стандартной библиотеке Ruby
http://www.rubycentral.com/book/tut_modules.html
Well, your classes can support all these neat-o features, thanks to the magic of mixins and module Enumerable. All you have to do is write an iterator called each, which returns the elements of your collection in turn. Mix in Enumerable, and suddenly your class supports things such as map, include?, and find_all?. If the objects in your collection implement meaningful ordering semantics using the <=> method, you'll also get min, max, and sort.

[shure.livejournal.com]

Mixin (or Flavour) можно описать как не полиморфный класс который предназначен для придания другим классам функциональности (не интерфейса!) главным образом для того что бы избежать (а) копирования кода (б) мн. наследования. В отличие от наследования, Mixin не преследут цель описать "is a" relation, а только добавляет код. Проблема мн. наследования mixin-ов как правило не возникет так как в подавляющем большинстве случаев mixin подмешивается в почти final класс. Простейший пример mixin-а - класс содержащий статические константы для удобства пользования в многих других классах. Специальный тип "виртуального" mixina - класс описывающий pure protected virtual functions предлагая главному классу реализовать их. В таком случае можно говорить про функцональность которую mixin требует от своего "главного класса". Интересный случай использование такого дизайна - несколько mixin-ов запрашивающих одинаковую функцональность от главного класса, который в свою очередь имплементирут функции всех mixin-ов "одним ударом" - то есть без повторения реализации этих функций.

[avva.livejournal.com]

Спасибо.
1) Может ли mixin, как класс, содержать данные (не статические)?
2) Не совсем понятен смысл вашего "виртуального mixin'а". Класс, в котором есть только pure protected virtual functions требует от меня их реализовать. Но при этом я не получаю полиморфизм, т.е. я не могу объект своего класса подставить в какое-то место, которое хочет получить объект класса mixin'a. Тогда что же я собственно получил? Что изменилось от того, что я "подмешал" такой mixin, по сравнению с тем, что я бы просто в своем классе написал ту же реализацию тех же функций с теми же именами, не упоминая нигде mixin?

[ex-ex-annut.livejournal.com]

к стыду, не доводилось ими пользоваться и читать про них
прочитала парочку статей и дискуссию в ньюс группах
насколько я понимаю mixin это в точности то, что Александреску называет policy

[haiut.livejournal.com]

1. Да-да, нечто похожее уже было, в Wiki это названо A Hoax interview transcript with IEEE's Computer magazine

2. Читал про mixin'ы в сети, и тут в комментариях. Не смог себя убедить, что это сколько-нибудь полезно, посему в обьяснения влезать не буду.

[haiut.livejournal.com]

obviously, the broken link (Hoax interview ..)in previous comment should point to -- http://www.chunder.com/text/ididit.html

[scolar.livejournal.com]

Не поленитесь прочитать Александреску.

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

Он уделяет довольно много внимания частному случаю использования mixin'ов - в качестве шаблонных параметров класса, от которых класс наследуется. Он называет это стратегиями (policies).

[12-drakon.livejournal.com]

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

Оффтопик: Авва, Вы знаете какой-нибудь легкий в обращении счетчик посетителей каждого топика в ЖЖ?

[avva.livejournal.com]

Нет, не знаю.

[master-nemo.livejournal.com]

класс!
А помнит ли еще кто-нибудь этот (http://linuxforum.ru/lofiversion/index.php/t11818.html) древний текст ?