>как, по вашему, нужно/не нужно?

Зависит от языка. В динамических, имхо, нужно в меньшей степени

>есть примеры хорошего использования?

mixins/разложение класса на стратегии

>есть ли чем его заменить?

В какой-то степени - Traits

yoghurt (16.03.2010 11:10:55)

Не нужно.
KISS!

urxvt (16.03.2010 11:18:11)

Как бы ответ на этот вопрос есть в факах у основателя С++

http://www2.research.att.com/~bs/bs_faq2.html#multiple

И вообще, в самом расп*датом ОО языке множественное наследование отсутствует, что символизирует!

yoghurt (16.03.2010 11:47:01)

Ты что-то перепутал, в CLOS есть всё.

arhibot (16.03.2010 11:50:10)

В каком?

> решил заняться дизайном языка программирования

Главный вопрос - зачем?

> что символизирует!

а аргументацию такого решения вы не припоминаете?

lester (16.03.2010 12:05:04)

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

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

Legioner (16.03.2010 12:19:03)

>а аргументацию такого решения вы не припоминаете?

"Не нужно!!". На самом деле не помню.

yoghurt (16.03.2010 12:19:44)

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

annulen (16.03.2010 12:19:54)

если я не ошибаюсь, аргументировали тем, что, как уже сказал Legioner, множественное наследование сложнее в реализации, а не правильностью или нет его использования

lester (16.03.2010 12:21:58)

Проектируешь и нас же просишь помочь в этом проектировании самим сделав за тебя часть работы...
Вот ты проектируешь - ты и думай нужно оно в твоём языке или нет.
Вообще, зависит от цели языка.
Считаю что нужно. Однако реализация не проста.
Те люди, что говонят "не нужно", либо просто не занимались проектами, где оно ужас как нужно, либо не помнят уже.
К примеру, геймдев вообще без множественного наследования обрастёт велосипедами и костылями. Да и не только.
Готов поспорить что в конце ты придёшь к мысли что, как минимум, миксины нужны. А это, по сути, то же множественное наследование.
Можешь глянуть D. Там нет множественного наследования. Однако есть миксины, которые, по сути, можно использовать как наследование. Все так и говорят: "в ди есть множественное наследование, но через миксины".
В общем, сам определи что ты хочешь и так и делай.

tia (16.03.2010 12:29:42)

зачем?

jtootf (16.03.2010 12:39:59)

А зачем пиво пьют?

Почему никто не начал с того что ООП вообще не нужно т.к являет собой "римские числа" проектирования программ? И что наследование - это дилетантское переизобретение работы со множествами, в данном случае - с множествами типов?

Absurd (16.03.2010 12:43:45)

я самим своим присутствием в треде молчаливо выражаю эту точку зрения

jtootf (16.03.2010 12:54:36)

Почему его сложно реализовать? По Страуструпу это легко, он писал, что сделал очень быстро.

Booster (16.03.2010 13:09:51)

> решил заняться дизайном языка программирования

Уже задизайнили, начиная с 50х годов. Последний стандарт был в 90х.

Разверните, пожалуйста.

placement_new (16.03.2010 13:31:30)

это будет 4.3, а мне ещё работать

jtootf (16.03.2010 14:01:42)

> По Страуструпу это легко, он писал, что сделал очень быстро.

даже мы быдлокодили на ЛОР :)

http://www.linux.org.ru/forum/development/3856495

lester (16.03.2010 14:07:42)

>говонят

Хм… -_-

Интересная опечатка.

srj (16.03.2010 14:22:18)

>Почему никто не начал с того что ООП вообще не нужно т.к являет собой "римские числа" проектирования программ?

А что ты предлагаешь взамен объектной декомпозиции? Хаскель и классы типов?

>А что ты предлагаешь взамен объектной декомпозиции? Хаскель и классы типов?

В настоящий момент я имею представление о типичной эволюции объектных абстракций во времени в типичном проекте. Оно меня не устраивает. Если бы меня в индустрии все устраивало - не писал бы я в Development.

Absurd (16.03.2010 15:01:29)

Ну что ты не даёшь элите помечтать? Элита же себя мыслит летающей высоко в небе с Лиспом и Хаскелем, а внизу ползающие Жабы и Плюсы. В палате №6 и не такое бывает до укола галоперидола.

>Элита же себя мыслит летающей высоко в небе с Лиспом и Хаскелем, а внизу ползающие Жабы и Плюсы.

Процедурный подход тоже лучше ООП.

Absurd (16.03.2010 15:29:13)

А как выглядит настоящий процедурный подход? А то что-нибудь вроде

perform (some_object, some_action, some_data);

Суть то же ООП

yoghurt (16.03.2010 15:39:33)

>Процедурный подход тоже лучше ООП.

А они друг другу не противоречат.

theos (16.03.2010 15:40:08)

весь вопрос в том, на каком месте в списке будет имя функции; некоторым это крайне важно

сферический в вакууме или практический?

jtootf (16.03.2010 15:45:20)

> сферический в вакууме или практический?

а какой вы можете продемонстрировать?

lester (16.03.2010 15:47:24)

>сферический в вакууме или практический?

Хотелось бы на оба посмотреть

Хотя с практическим-то я, пожалуй, знаком, ибо простыней кода на QBasic и Pascal в детстве понаписал несколько тетрадок :)

yoghurt (16.03.2010 15:54:46)

>>Процедурный подход тоже лучше ООП.

>А они друг другу не противоречат.

ООП его выворачивает наизнанку, делая первичным интерфейс а не функционал.

Absurd (16.03.2010 15:56:12)

ко мне можно на "ты". могу сферический - разбиваем модуль на процедуры, изменяющие глобальное (локальное по модулю) состояние. весь обмен данными выполняется через расшаренные области памяти, отличающиеся плоской (бинарно стандартизованной) структурой, прозрачно сериализуемой для работы с потоками ОС. поскольку по умолчанию вся обработка выполняется in-place, синхронизация выполняется по Хоару (CSP, блокировки, критические секции, семафоры, условные переменные)

в реальной жизни чисто процедурный стиль смешивается с функциональным (процедуры возвращают значения, используются указатели на функции в качестве first class object, используются структуры указателей на функции, etc)

jtootf (16.03.2010 15:59:40)

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

jtootf (16.03.2010 16:02:50)

>то есть делает шаг от теории множеств к теории категорий

По мне так функционал первичен. Приведу аргумент Изи Крейнина по поводу требования высокой квалификации для строительства интерфейсов:

class FaceRecongizer {
public:
  virtual double calcFaceLikeness(const TGAImage& sample1, const TGAImage& sample2) = 0;
};

Absurd (16.03.2010 16:12:20)

Капитан Очевидность, не узнал вас с таким цветом волос. Все знаю что крайности _в любых_ направления зло.

theos (16.03.2010 16:35:31)

Согласен! Более того. На мой взгляд средства языка должны быть отражением алгоритма в голове программиста. Страуструп в Дизайне и эволюции пишет, что не знает какое множественное наследование более правильное -- виртуальное или нет. Потому что в голове нет этому аналога. Имхо, единственный повод для введения наследования -- экономия на повторном написании(изменении) кода, и, если есть способ это сделать без наследования, было бы очень здорово!

А по сему к вам вопрос, какие есть менее дилетантские и более целостные концепции?

Хаскель, кстати, идейно хорош!

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

А то у всех свои понятия о строках(char*, string, QString, CString, ...). И хрен поймешь, что лучше использовать в конкретном месте.

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

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

А по сему к вам вопрос, какие есть менее дилетантские и более целостные концепции?

По-моему одна из таких это шаблонный метод. Да и вообще виртуальные методы.

Booster (16.03.2010 18:16:48)

Да и вообще ООП.

tia (16.03.2010 18:19:07)

Агрегация

roy (16.03.2010 18:27:03)

>Наконец-то интерфейсы оторвали от типов. Я могу работать в своем коде с любой строкой(которая удовлетворяет указанному интерфейсу), а не с конкретной.

Только не говори что тебе ООП это сделать не позволяла.

theos (16.03.2010 18:27:58)

>единственный повод для введения наследования -- экономия на повторном написании(изменении) кода

это же является и единственным поводом для процедурного подхода. Когда-то программы писали последовательно и набивали на перфокарты))

на самом деле, наследование ни разу не противоестественно - детализация объекта

annulen (16.03.2010 18:31:17)

Всего года два назад ещё считал, что нужно.

По зрелому размышлению понял, что когда есть потребность во множественном наследовании - то это, скорее всего, ошибка в дизайне :)

KRoN73 (16.03.2010 18:33:26)

> у всех свои понятия о строках(char*, string, QString, CString, ...)

что мешает добавить соответствующий конструктор или метод доступа? в QString нет никаких проблем с тем чтобы создать объект из строки типа char* или получить char* или string из нее.

annulen (16.03.2010 18:34:41)

>Почему его сложно реализовать?

Миф такой распространённый :)

KRoN73 (16.03.2010 18:35:05)

http://www.haskell.org/haskellwiki/OOP_vs_type_classes

jtootf (16.03.2010 18:36:11)