Что делает ООП - ООП?

Имея структуру man, как мы инкапсулируем её переменные health и sex?

С помошью модулей, например. Или pimpl, например. Никакой сложности это не представляет.

Ну как-то и не хожу

То есть если у нас есть класс, у которого все поля публичные - то он не класс, а структура?

Или наоборот, у нас есть структура, но есть соглашение, что напрямую работать с ней нельзя, а надо через getter/setter/какие-то другое функции - вот и инкапсуляция.

Но зачем тогда что-то утверждаешь, рассмотрев только с одного ракурса?

Если модулями, то сколько экземпляров man можно создать? А как с помощью pimpl?

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

Ну, я со своего рассматриваю, кто-то с другого. Так и собирается целое.

А второе, наверное, всё-таки нет ... ошибочное обращение напрямую

Так ООП придумано для давания тупым макакам по рукам?

Ты прекрасно понимаешь что именно я имел ввиду, троллить незачем :-)

Честно говоря, нет. Потому что в CLOS методы не привязаны к классам/объектам.

Да, именно для этого. Не ходите туда :)

Что делает ООП - ООП?

ООП - ООП равно 0

К.О.

Как найти ту тонкую грянь

Лапши на COBOL асме перле почитай, потом «тяжпромпроцедурного программирования» на цешке с кашкой свичей на неск. экранов, макросов и копипастой, выходами из вложенных циклов по goto, — потом что-нибудь «в меру» объектное, поймешь разницу :)

совсем невалидный аргумент

Дык... я вынужден. Хотя в целом не жалуюсь. Инструмент есть, работа налажена. Ну не орать же «все гавно, надо переписывать!». Печка сложена, пирожки пекутся.

Для упоротых — безусловно. Кашку из классов ООП писать не запрещает :)

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

Ну, ясное дело :) Но ваш вопрос звучал как: «ЯП были придуманы, чтобы не путали eax и ebx?»

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

Да сколько угодно. Доступ к полям будут иметь только функции из того же модуля, а остальные будут только через «интерфейс» модуля работать.

А как с помощью pimpl?

Ну хотя бы так:

// .h

typedef struct my_class my_class_t;

void my_class_method(my_class_t * obj, ...)

// .c

struct my_class
{
    int x;
    int y;
};

void my_class_method(my_class_t * obj, ...)
{
    obj->x += 10;
}

dude = man.new();
man.get_attribute(dude, 'health');

man - модуль, экспортирующий функции new и get_attribute. Так сколько экземпляров можно создать?

То есть если у нас есть класс, у которого все поля публичные - то он не класс, а структура?

Что значит «есть класс»? Вы не путайте понятия какого-то языка и теоретические определения.

В C++ вон вообще структуры и классы, как языковые сущности, отличаются только политикой public/private по умолчанию, а так это одно и тоже.

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

А в том, что если взять процедурный и ООП код,

я всё ещё не понял что такое 'ООП код'

https://pp.vk.me/c514301/u3421463/video/l_0df10219.jpg (не перегибай)

А все обучение строится на «скачке понимания». (Научить чему-то людей вообще нельзя — это изнутри приходит) Ты сначала что-то пробуешь руками — вроде получается... Потом начинаешь понимать, что получается какая-то лажа — когда кот твоего маленького «проэкта» превышает пороговое значение понимабельности полученной «кашки» через две недели/месяц/год, вызывая недоумение «кто блжад это написал? Как, я и написал?» — а вносить изменения становится накладно :) Начинаешь интересоваться, а как «более лучдшы говнокодить» и почему то что раньше получалось - получалось херово. Т.е. тебе было сначала норм — а потом кто-то посмотрел в твой кот... И в лучшем случае ничего не понялв более лучшем это был ты — через месяц, когда почитал умных книжек где разобраны «типичные ошибки» :))) Чувство меры приходит именно с опытом — без него ты и в ООП будешь городить монстров.

спасибо. можно такой же пример с модулем?

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

мощно.

Для координации коллектива разработчиков, for politeness sake.

Объект - сущность в памяти, которая имеет свои свойства и поведение, определяемое методами.
Всё есть объект, объекты общаются посредством сообщений.

Это не пимпл у тебя, это opaque type. Пимпл это

// .h

struct Public {
    void *pimpl;
    ... // public fields
};

void foo(Public *p);

// .c

struct Private {
    int private_var;
};
#define impl(p) ((struct Private *)((p)->pimpl))

void
foo(Public *p)
{
    impl(p)->private_var = 1;
}

Это позволяет (помимо инкапсуляции) менять Private без потерь ABI.

Это не пимпл у тебя, это opaque type

пимпл является разновидностью opaque type, если что.

Какие вещи специфичны только для ООП?

Никакие.

Не знаю, что он имел ввиду под модулем, но когда в Lua надо скрыть данные*, то я юзаю:

local M = { } -- module
local pp = setmetatable({ }, { __mode = "k" })

function M.new()
    local object = { } -- public
    pp[object] = { } -- private
    return object
end

function M.foo(object)
    pp[foo].private_var = 1
end

return M

Здесь pp чисто локальная для модуля таблица и извне доступна только через отладочный модуль.

* - не с целью запретить макакам что-то сделать, а чтобы при обходе ключей не светились, например

Согласен, но мне всегда казалось, что p в pimpl это именно Impl * каким-то из первых членов.

Делает 0

А вот это уже годно.

Ну если сказать мягко, то, да, для координации коллектива ))

А ядро уже переписали на С++?

Использовать ООП на языке, в котором отсутствуют соответствующие синтаксические конструкции можно.

Сам себе противоречишь.

то же, что отделяет теоретико-категориальный подход от теоретико-множественного, если вы понимаете о чём я

то же, что отделяет теоретико-категориальный подход от теоретико-множественного,

Это Вы с ФП перепутали. Настоящее ООП с этим ничего общего не имеет, только квази-ООП языки для конторского быдла, типа Java.

Математическая модель, наиболее близкая к ООП — это модель Акторов.

Это Вы с ФП перепутали

нет

Настоящее ООП с этим ничего общего не имеет

нет

квази-ООП языки для конторского быдла, типа Java

нет

нет

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

и почему я должен это сделать, интересно?

Если Вы хотите обосновать свою позицию, Вы это сделаете. В противном случае, Ваши слова, не более чем плод воспаленной фантазии.

и какая же у меня позиция?

Вот эта.

то же, что отделяет теоретико-категориальный подход от теоретико-множественного

замечательно. и что же отделяет первое от второго?

Это не важно. Важно то, что то что отделяет ООП от других парадигм, не имеет ничего общего с тем, что отделяет теокат от теоретико-множественного подхода (а это категории, естественно, кэп подсказывает, что именно в этом основное отличие, в ТМ категорий нет)

И то и другое выразимо в ООП и является частными случаями, не более того.

это категории, естественно

нет

не имеет ничего общего с тем, что отделяет теокат от теоретико-множественного подхода

как ты можешь делать сравнение с тем, о чём ничего не знаешь?