ооп, иерархии, подмножества

Мне другое интересно, как при помощи этих интуитивно ожидаемых отношений делать реальный код? Я половину слов в посте не понял, но скажем есть подмножество A, есть подмножество B, мы строим их объединение получаем подмножество U. Или строим их пересечение, и получаем подмножество C.

Если A и B классы (в смысле С++/Python) то скажем при помощи множественного наследования худо-бедно делается U и он будет даже работать. В питоне я могу сделать извращенное «наследование» а ля пересечение, и на его основе сваять С.

Теперь, если A не класс, и B не класс, то что с этим вообще можно сделать? Что такое A и B? Как вообще из этого самого подмножества получить в итоге что то работающее? Как подмножество устроено?

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

Теперь, если A не класс, и B не класс, то что с этим вообще можно сделать? Что такое A и B? Как вообще из этого самого подмножества получить в итоге что то работающее? Как подмножество устроено?

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

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

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

Я как-то предлагал обсудить идею, которая в теории может упростить или упразднить существующие методы «наследования», но она требует отказаться от текста, и лор ее не поддержал. Надо было не с того наверное начинать.

в Jetbrains MPS от текста отказались. В каком-то смысле. И ничо, поциент жив и здравствует... Давай сюда идею )

Что-то подсказывает, что U скорее должно агрегировать AB, чем быть их объединением. Но тут на словах легко быть Львом.

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

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

Что такое A и B?

миксины, например, или аспекты

Как вообще из этого самого подмножества получить в итоге что то работающее? Как подмножество устроено?

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

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

попробую сформулировать: суть ООП не состоит в «наследовании, инкапсуляции, полиморфизме».

суть ООП состоит в реализации некоторой «объектной модели», показывающей как объекты работают в рантайме.

эта модель может быть построена на этих трёх концепциях «наследование, инкапсуляция, полиморфизм» (назовём ее оо-модель-С++), а может быть на других «посылка сообщений, позднее связывание» (назовём её оо-модель-смоллток, она же в objective c), а может быть основана на других принципах «методы вне классов, мультиметоды, метаобъектный протокол, динамическое расширение» (назовём её оо-модель-CLOS), или на каких-то других вообще принципах (так, автор C object system Laurent Deniau приводит мультидиспетчирезацию сообщений и мультифорвардинг сообщений, как основные способы построения «динамической объектной модели»).

вполне логично, что ООП можно построить и на каких-то других ортогональных принципах.

например, в Oberon-2, Компонентно-Ориентированном Программировании приводились другие принципы на уровне модулей.

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

например, возьмём такие штуки как traits, mixins, aspects.

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

метаобъектный протокол,протоколы и категории в Objective C и интерфейсы — это тоже в некотором роде одно и то же, по-разному выраженное.

да, а Бертран Мейер в тёплом ламповом Эйфеле тоже придумывает свою терминологию: специализацию и универсализацию.

Я как-то предлагал обсудить идею, которая в теории может упростить или упразднить существующие методы «наследования», но она требует отказаться от текста, и лор ее не поддержал.

озвучь ещё раз

пример какой-нибудь приведи

Аф!

Анончик, охота обсудить, но времени прям щас нет. Блин.

Я половину слов в посте не понял

Это норма, он сам свой понос, только понимает.

Я знаком и с популярной (крестовой) моделью ооп, и со смолтоковой, и со странными, в т.ч. самописными моделями экспериментировал, но все они все отличались формальной жесткостью. То есть инкапсуляция она либо есть, либо ее нет, например. Когда ты берешь чужой ооп-класс или набор оных, ты опираешься на публичный интерфейс, а внутрь лазить нельзя, т.к. детали реализации долго не живут. Но при разработке собственного продукта ты волен опираться на эти детали, т.к. сам варишься в этом супе (даже юникс-фс имеет ugo и acl, ну вы понели). С одной стороны, это хорошо, когда все формализовано, но иногда хочется включить первую передачу и форсировать проблему, взять ее грубой силой, и в жесткой модели (а мы связаны границами классов/интерфейсов) ты теряешь полезные по сути своей инструменты валидации, делая например полупубличный доступ к тому, что является частью инварианта системы, размазывая его по коду без к-л семантического контроля. Хорошо говорить об абсолютной стройности, но все знают, что есть такое слово дедлайн, кроме того некоторые вещи невозможно красиво формализовать в ооп-модели, да еще с обычными ограничениями языка (там неймспейсов нет, тут базового класса). Интересно было бы пощупать ооп, в котором структурные границы задавались бы не жестко-синтаксически, а путем описания инвариантов и возможностей схемы, например не указывать вовсе public/protected, а также управлять областями видимости (сейчас это куцый friends), делать умные интерфейсы, которые знают о твоем наборе внутренних свойств и т.п. Причем не жестко, а просто с показателем «говнокодности» участка.

В общем-то тот тред был как раз о редакторе, который позволил бы управлять этим всем графически естественным образом, например контролировать вложенность декларативных контекстов, где внутри все друг-друга видят, а снаружи не очень, причем не как жесткое правило, а как статистика: в этом контексте 5 красных использований (читай нарушение инкапсуляции), а между этими двумя их нет. Я уже на своем опыте убедился, что прототипирование лучше делать на слабой схеме (перл и т.п.), а продукт писать на сильной. Как сделать так, чтобы прототип можно было детализировать и рефакторить прямо по месту, оставляя непродуманные места тупыми хаками — вот основной вопрос. Кроме того я там описывал, как можно упростить код путем уменьшения too wordy, и еще пару интересных мелочей, но это больше следствия.

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

зы: Я не претендую на мегавидение и прорыв, и на 98% уверен, что генерю тупняк, но мне интересна эта область и почему в ней так, как сейчас, а не по-другому.

Eiffel смотрел? Там есть инварианты, пост-условия и пред-условия, вместо friend механизм, позволяющий указывать, кому(каким иерархиям) и что(какие разделы класса) ты открываешь.

Вроде не смотрел, на досуге гляну, спасибо.

Но там таки ООП с классами. Так что может тебе и не интересно.