Да.

Нет. Какие ваши доказательства?

в твоих аналогиях стало так много от Катющика, что даже немного страшно

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

Свободное время и работа - разные классы же. Что-то вроде

interface Activity {
  void doShit();
}

class Wörk implements Activity {
  void doShit() {
    doWörk();
  }
}

class Hobby implements Activity {
  void doShit() {
     doSomeMeaninglessShit(); 
  }
}

class Football extends Hobby {
 ...
}

class Plumber extends Wörk {
...
}

class Mario implement Human {
  private Activity wörk = new Plumber();
  private Activity hobby = new Football();

  ...
}

Как-то так.

Всем теперь нужно переезжать в волшебный мир эльфов, где не ломается совместимость между версиями?

Чего ты заладил про совместимость? Она тут вообще не при делах. Ещё раз: я пишу библиотеку не подозревая о том, что ты захочешь наследоваться от двух потомков одного класса. А ты пользуешься библиотекой и страдаешь из-за того, что наследуются они не так, как хотелось бы тебе.

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

Другое дело, что таких случаев стараются избегать. Как раз из-за «удобств» с этим связанных.

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

— Профессия Васи — слесарь.
— Хобби Васи — футболист.

Вася не должен быть слесарем или футболистом. Он будет человеком с указанными профессией и хобби. В результате даже наследование вообще теряет принципиальную надобность (можно указать, что «Вид — человек»), превращаясь лишь в синтаксический сахар.

Я тоже после Си долго страдал от отсутствия множественного наследования в разных языках. Пока не дошёл до этого уровня декомпозиции. И всё стало намного логичнее и проще.

Вася не должен быть слесарем или футболистом

он должен наследовать от них, капитан как бы намекает

Он будет человеком с указанными профессией и хобби.

будет, кто спорит

В результате даже наследование вообще теряет принципиальную надобность (можно указать, что «Вид — человек»), превращаясь лишь в синтаксический сахар.

то есть, ты предлагаешь всю реализацию писать в каждом экземпляре что ли? И это прогресс? Идея совместного использования кода — нинужно?

Пока не дошёл до этого уровня декомпозиции. И всё стало намного логичнее и проще.

Не совсем понятно, что тут имеется в виду под «уровнем декомпозиции», можно чуть подробней?

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

Это далеко не единственный случай, когда «я пишу библиотеку не подозревая о том, что ты захочешь». Это касается огромного кол-во аспектов и наследование тут дело даже не десятое. И, да, удовлетворить всех не получится никогда.

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

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

А когда у anonimous'а уровень аналогий и рассуждений был выше?

Катющик,между прочим, правильно делает, что фаршмачит ТО, он всяко умней мейнстримных физиков, которые уверовали в эту ахинею, и уже столетие не могут снять лапшу с ушей, которую им навешал пердун-аутист(а ведь это тру-стори, не шутка!). Я, правда, не знаком, конкретно, с его критикой, но саму критику адабрямс:)

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

А я помню, как такой вод кондовый инженер как ты выпускник престижного вуза с красным дипломом, впал в ступор и краснел передо мной как девочка, когда я ему полчаса вдалбливал, что 2 последовательно включенные активные нагрузки потребляют меньше мощности, чем они же, включенные параллельно. Он нервно лепетал что то про закон ома, и садился за расчеты, исписал, сука, пол тетради. И такие истории повторяются постоянно. Так что девочкам своим рассказывай про энштейнов, и фундаментальные основы физики, а в моих глазах вы были и останетесь банальными дебилами-зубрилками. Говорящий не знает, а знающий не говорит.

Я, кстати, давно заметил, что все что ты говоришь — это не твои рассуждения, а что-то вычитанное где то в «умных» книжках. В тебе совершенно не видно твоих собственных идей.

он должен наследовать от них, капитан как бы намекает

Наследовать — это быть. И тем, и другим. Ваш К.О. :)

то есть, ты предлагаешь всю реализацию писать в каждом экземпляре что ли?

Нет. Я предлагаю каждую классификацию описывать отдельным классом. И не смешивать разные классификации в одном классе.

Не совсем понятно, что тут имеется в виду под «уровнем декомпозиции», можно чуть подробней?

Если мы описываем типы сущностей «профессия» и «хобби» внутри одного класса, то получаем, тавтология, смешение двух разных сущностей в одном классе. Что приводит и к усложнению разработки, и к неоднозначностям... Например, от балды, на что я натыкаюсь часто. Нужно, скажем, вывести название профессии или хобби. В случае множественного наследования придётся писать в суперклассе профессии метод occupation_title(), в суперклассе хобби — hobby_title(). Чтобы потом выводить как print(vasya.occupation_title()) или print(vasya.hobby_title()). В итоге, получится, что все типовые имена методов придётся снабжать префиксом. Класс хобби будет заполонён «hobby_...()» методами...

А вот в случае отсутствия множественного программирования все наши классы становятся идентичными, имеют чёткую систему именования методов, а обращения к ним идут через возвращение соответствующего класса, например, print(vasya.hobby().title()). Архитектура получается более гибкой, лёгкой, однозначной. Особенно, когда начинается активная передача классов и цепочные вызовы.

Например, у нас есть класс, выводящий информацию о роде занятий переданного объекта. Если мы заведём суперкласс «человек», от него два субкласса «человек с профессией» и «человек с хобби» и соединим их потом в субклассе Вася, то всё пока будет нормально.

Но затем мы захотим ввести класс «NPC» («компютерный персонаж»), который тоже будет иметь «профессию» и «хобби». И, опаньки, нам придётся заниматься копипастом, дублируя эти сущности между «человком» и «NPC».

А в случае с примесями у нас будут независимые классы «NPC» и «человек», которые будут обладать полями «хобби» и «профессия», ссылающимися на опять независимые классы. Всё в одном экземпляре, никакого дублирования, никаких неоднозначностей и всё логично.

И, опаньки, нам придётся заниматься копипастом, дублируя эти сущности между «человком» и «NPC».

Чтоб не было копипастов в реализации - есть дженерики и шаблоны.

А в случае с примесями у нас будут независимые классы «NPC» и «человек», которые будут обладать полями «хобби» и «профессия», ссылающимися на опять независимые классы. Всё в одном экземпляре, никакого дублирования, никаких неоднозначностей и всё логично.

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

Я предлагаю каждую классификацию описывать отдельным классом. И не смешивать разные классификации в одном классе.

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

Если мы описываем типы сущностей «профессия» и «хобби» внутри одного класса, то получаем, тавтология, смешение двух разных сущностей в одном классе.

Не понятно, причем тут тавтология. Почему одна сущность не может реализовывать поведение 2-х сразу? Тот же Вася, к примеру.

например, print(vasya.hobby().title()).Архитектура получается более гибкой, лёгкой, однозначной.

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

Но затем мы захотим ввести класс «NPC» («компютерный персонаж»), который тоже будет иметь «профессию» и «хобби». И, опаньки, нам придётся заниматься копипастом, дублируя эти сущности между «человком» и «NPC».

Какая паста? Ты точно также его можешь отнаследовать от футболиста и слесаря, или от кого угодно еще, чье поведение надо реализовать в нем, никто не мешает.

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

Примеси — это дублирование по определению. Ты копируешь там поля одного класса в другой.

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

А в некоторых хороших языках можно выбирать порядок наследования.

http://www.youtube.com/watch?v=EiOglTERPEo

Но ты по этой ссылке ничего не осилишь, как это не печально.

Я пишу на Io, там можно это делать. Так что ссылка твоя меня нибет, отдыхай.

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

идиот, ты ведь сам пишешь

можно выбирать

кто выбирает тогда, если не ты? дезигнер твоего недоязычка?

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

но эти он не отличается от любого другого динамического недоязычка

а пистон не динамический? ну ты клоун. Все адью, не стоишь ты внимания.

и, кстати, я так понял, там речь идет о методе super, так вот аналог этого дерьма есть в Io, но это вообще не о том, в ио можно просто переопределить порядок лукапа в предках, а супер — всего лишь отсылка к классу уровнем выше изнутри потомка. Иными словами, наивное детское говнецо

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

нет. мы наследуем его от класса «Человек». а уж класс «Человек» может содержать в себе массив функторов.

а вот в вашем случае, если Вася устроится на другую работу, delete Вася?

а вот в вашем случае, если Вася устроится на другую работу, delete Вася?

Кстати, да. И что делать, если у него может стать несколько хобби? :)

перенаследовать, его от филателиста. Я хз, что за языки вы используете, где могут возникнуть проблемы на пустом месте. Речь тут о Ъ в основном. Проблемы быдлоплюсов и прочего говна тут не обсуждаются, это не настоящее ООП, там от ООП только названия.

И что делать, если у него может стать несколько хобби? :)

Наследовать от всех. На то оно имножественное, что позволяет решать именно такие задачи.

Миксины я не беру в расчет, они в Ъ не катят.
Я честно говорю, уважаю Алана Кея, он говорит много правильных вещей, его позиция и взгляды мне близки. Но тут ИМХО, он сделал ошибку.

<я признаю, что мои взгляды узки, но неправ создатель термина ООП>

Я считаю, что ты — нелепейший тролль.

ты о чем вообще лепечешь? Ты что, хочешь сказать, что ООП в смоллтоке основано на говнокопировании, или к чему ты это цитируешь?

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

нет. мы наследуем его от класса «Человек». а уж класс «Человек» может содержать в себе массив функторов.
а вот в вашем случае, если Вася устроится на другую работу, delete Вася?

А если прилетело НЛО и Васю превратили в строгга? Тут либо надо пользоваться реализацией ООП, которое позволяет полную динамику, но тогда получаем медленную реализацию с массой факапов в рантайме, либо фиксируем некоторые моменты, но получаем оптимизированный и проверенный на этапе компиляции код.

Я че то непонял, ты на Кея чтоли катишь? че ты тут вообще за бред несешь?

Да, ты рельно ничего не понял. Иди перечитывай.

So, this product doesn't support inheritance, right?" «that's right». «And it doesn't support polymorphism, right?» «that's right» «And it doesn't support encapsulation, right?» «that's correct». «So, it doesn't seem to me like it's object-oriented».

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

Ладно, снизойду. Раз Кей придумал термин, то нечего с ним спорить, что именно он имел ввиду под ООП. По ссылке то, как слился какой-то тип на конференции, встретивший Кея лично. В этом треде сливаешься ты. Разжеванная аналогия тебе понятна?

Перечитал, тебе еще логику подучить надо.

перенаследовать, его от филателиста.

ну вот и приплыли. чем это проще коллекции функторов? как с точки зрения принципиальной, так и с точки зрения синтаксического сахара.

как только начинается «перенаследование» автокоплита-то больше не будет (либо будет загаженый бесполезный автокомплит). а ну да, во всяком шлаке вроде io его и так нет.

Проблемы быдлоплюсов

вы просто в них не умеете

Раз Кей придумал термин

Разве он придумал Simula, где впервые вместе появились объекты, классы, наследование, виртуальные процедуры и т.д. и т.п.? И вообще, есть какие-то пруфы, что именно он придумал термин, кроме его собственных заявлений об этом?

Раз Кей придумал термин, то нечего с ним спорить, что именно он имел ввиду под ООП.

То есть, кроме смоллтока ООП языков не существует? оукей, логика твоя очень логична, не поспоришь, LOL

А если прилетело НЛО и Васю превратили в строгга?

массив (в общем случае — коллекция) функторов решает и этот вопрос без проблем: просто убираете у васи Все функторы, связанные с «человеком» и добавляете связанные со строгом или кем душе угодно

ОК, фантазер, ты безнадежен. Я ничего такого не говорил, учись читать, затем учи логику.

Terminology invoking «objects» and «oriented» in the modern sense of object-oriented programming made its first appearance at MIT in the late 1950s and early 1960s. In the environment of the artificial intelligence group, as early as 1960, «object» could refer to identified items (LISP atoms) with properties (attributes);[9][10] Alan Kay was later to cite a detailed understanding of LISP internals as a strong influence on his thinking in 1966.[11] Another early MIT example was Sketchpad created by Ivan Sutherland in 1960–61; in the glossary of the 1963 technical report based on his dissertation about Sketchpad, Sutherland defined notions of «object» and «instance» (with the class concept covered by «master» or «definition»), albeit specialized to graphical interaction.[12] Also, an MIT ALGOL version, AED-0, established a direct link between data structures («plexes», in that dialect) and procedures, prefiguring what were later termed «messages», «methods», and «member functions».[13][14]

The formal programming concept of objects was introduced in the 1960s in Simula 67, a major revision of Simula I, a programming language designed for discrete event simulation, created by Ole-Johan Dahl and Kristen Nygaard of the Norwegian Computing Center in Oslo.[15] Simula 67 was influenced by SIMSCRIPT and C.A.R. «Tony» Hoare's proposed «record classes».[13][16] Simula introduced the notion of classes and instances or objects (as well as subclasses, virtual methods, coroutines, and discrete event simulation) as part of an explicit programming paradigm. The language also used automatic garbage collection that had been invented earlier for the functional programming language Lisp. Simula was used for physical modeling, such as models to study and improve the movement of ships and their content through cargo ports. The ideas of Simula 67 influenced many later languages, including Smalltalk, derivatives of LISP (CLOS), Object Pascal, and C++.

ну вот и приплыли. чем это проще коллекции функторов? как с точки зрения принципиальной, так и с точки зрения синтаксического сахара.

Так может вообще нахрен эти объекты, а Вася будет структуркой из двух хэш-табличек - поля и функции-методы?

v.methods[ DO_JOB ]( v );

Отличный способ ящитаю.

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

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

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

С чем ты вообще споришь я не понимаю.

и вот ещё такой вопрос: Вася взял мяч, теперь у него появилась пачка методов «играть с мячом». Вася отложил мяч, теперь у него исчезла пачка методов «играть с мячом». Вася взял книгу, Вася пришёл на кухню...

что вы предлагаете: каждый раз раз наследовать-перенаследовать? очуметь...

LISP atoms) with properties (attributes)

в этом утверждении содержится противоречие. Атом — это единое целое, неделимое, по определению, тогда как объект — это как минимум множество. Уж если и искать в девственном лиспе объекты, так это будет assoc в комплекте с list. это примитивный объект без сахара.

for the functional programming language Lisp

лисп, кстати, не функциональный язык, это распространенное заблуждение. Его функциональность примерно такая же, как в JS. Беллетристика какая-то

Катющик,между прочим, правильно делает, что фаршмачит ТО, он всяко умней мейнстримных физиков, которые уверовали в эту ахинею

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

вообще-то, так в приличных (ММО)РПГ и делают.

а ещё, подобного рода подход используется в реляционных (и не только) базах данных, только реляционная БД — суть обобщение.

но, в общем случае, так делать не надо: без этого автокомплит не будет работать

Ты какой-то упоротый

Спасибо.

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

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

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

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

С чем ты вообще споришь я не понимаю.

Я спорю?! Это тебя что-то постоянно не устраивает и ты рвешься об этом рассказать.

Да ладно. А ничо, что ТО противоречит квантовой механике?

вообще-то, так в приличных (ММО)РПГ и делают.

Так ты в глаза не видел код действительно приличных "(ММО)РПГ". Не стоит рассказывать о своих фантазиях.

а ещё, подобного рода подход используется в реляционных (и не только) базах данных, только реляционная БД — суть обобщение.

К счастью большинство хороших реляционных СУБД открыты, не покажешь где там в коде используется такой подход?

но, в общем случае, так делать не надо: без этого автокомплит не будет работать

Вот мы и выяснили что и почему надо делать.