Почему боятся ООП?

Ну начал копипастить вики, копипасть до конца

«Практически все лазерные принтеры 1990-х годов поддерживали PostScript в качестве основного языка»

А поэтому они тупо забили на поддержку новых версий

Да. Но не наговнокодили, а родили другое промежуточное представление

«Таким образом, PostScript вытесняется из офисов языком PCL»

Изобрели два промежуточных ЯП. И теперь нужно как для первого код поддерживать, так и для второго писать? Молодцы, «не наговнокодили». Количество классов для двух промежуточных форматов сам посчитаешь или мне посчитать? А потом, ещё посчитай когда твои макаки изобретут 3-й промежуточный формат. Чатгпт их много выдала, там больше 3. Кто знает какой будет следующий в тренде?

Так чтобы с этими состояними эффективно работать нужная целая СУБД и язык запросов SQL.

Нет. Легко делается реализация в памяти с индексами.

Работают такие состояния на порядки медленне состояний на переменных или структурах.

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

PostScript

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

И штрихкоды разве PostScript умеет? В смысле, как из него потом в EZPL преобразовывать?

Нет. Легко делается реализация в памяти с индексами.

Это обычная hashmap или treemap. Опять частный случай ООП.

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

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

таблицы не требует нелокального перехода по ссылке на каждую строку

Рука лицо. Ладно я устал, я мухожук. Удачи.

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

Это же Вы джаву в пример приводили. Как в ней сделать сотню объектов так, чтобы скорость

s = 0;
for(Obj o : objects) {
  s += o.getSum();
}

была не ниже, чем

s = 0;
p = &tab[0].sum;
for(int i = 0, i <= n; i++)
{
  s += *p; p += ROWSIZE;
}

?

Redux

Частный случай ООП

Nyet. Это частный случай механизма для управления изменяемым состоянием (здорового человека). Мешанина из взаимосвязанных (во многих смыслах) объектов в этом вашем ООП — тоже механизм для управления изменяемым состоянием (курильщика).

Видим объекты, видим методы

— Ты методы видишь? И я нет. А они есть!

мультиметод

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

Не надо никого перекомпилировать, просто пишешь ещё один метод под новую комбинацию параметров. Старые методы остаются как были, их вообще трогать не нужно.

obj.meth(arg1, arg2, …) против meth(obj, arg1, arg2, …). Одно и то же.

В контексте оно может и одно и тоже. Но так-то разница есть:

1. Метод позволяет инкапсулировать данные объекта, а функция нет.
2. Автодополнение в первом случае проще и логичнее.
3. 25 < 26.

Раньше по теме ещё было, что класс и модуль - одно и то же, с разным синтаксисом. Но у модуля же нет экземпляров (или один экземпляр). У класса может быть множество экземпляров. И поведение экземпляров может отличаться.

ващет у Кнутия «во времена» до структурные работа с массивами наборов синтаксически как набор массивов

как в обьектном подходе который тяготеет к pod+механизм резолва методов минимизировать количество разыменнований при обращении к полям?!

один из методов (см Елизарова кстати с hft на как раз таки джабе)

перевод массива объектов в обьект массивов

а так то да всё есть ООП

1. Почему? Данные в обоих случая в obj. Более того, в случае функции я могу написать

struct myObject;

struct myObject *obj = createObj(...);
meth(obj, ...);

а в случае класса я обязан писать поля класса в .h и перекомпилировать все программы, использующие класс, если у него добавилось поле или изменился тип поля. Или добавился метод. Поэтому инкапсуляция лучше через функции.

2. Согласен. Наверное, единственный объективный плюс методов через точку по сравнению с обобщёнными функциями.

3. Можно тоже писать без пробелов: meth(obj,arg1,arg2,…)

Это же Вы джаву в пример приводили. Как в ней сделать сотню объектов так, чтобы скорость

Использовать Foreign Functions & Memory API подвезённый в последние версии. По сути вы вручную запрашиваете у ОС память и размещаете свои данные. Дальше задаёте структуру и выравнивание полей. А затем как в Си работать. Можно даже AVX инструкции использовать.

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

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

Использовать Foreign Functions & Memory API

Из этого сделать объект Java не получится нормально.

Дальше задаёте структуру и выравнивание полей.

Ну вот. То есть, если надо быстро, то никаких объектов. Только данные.

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

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

Ну вот. То есть, если надо быстро, то никаких объектов. Только данные.

Так вы чем читаете? Я и говорю, что ООП гибче. Если нужно удобно юзаем классы, если нужно быстро юзаем структуры. То, что в джаве до этого не сразу доперли, так это издержки реализации. В том же сишарпе это из коробки давно есть.

В ООП языках почти наверняка, даже если делать массив структур, то элементом массива будет не структура, а указатель

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

Я и говорю, что ООП гибче.

Это ООП:

По сути вы вручную запрашиваете у ОС память и размещаете свои данные. Дальше задаёте структуру и выравнивание полей. А затем как в Си работать. Можно даже AVX инструкции использовать.

???

Но это издержки реализации, а не конкретно ООП.

Строки как данные всё равно заметно отличаются от объектов ООП. В частности, если в разных строках разные типы данных, то просто будет дополнительная колонка «тип», но у каждой строки будут все колонки всех допустимых типов.

Ещё есть объекты не ООП. Например, в Haskell. Состояния в монадах, для обработки изменения состояний есть удобные интерфейсы (do, линзы, …), явное указание наличия или отсутствия изменения состояния позволяет на порядок упростить тестирования (вплоть до генерации случайных тестов по указанию инварианта в комментарии).

Это ООП

Да. Все операции происходят в ООП парадигме. Подробнее в документации Foreign Functions & Memory API.

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

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

обьявленно [3]obj

obj это f,i,e,l,d

однако в памяти поля расположаться так:

f[0],f[1],f[2],e[0],e[1],e[2] .....d[2]

Почему? Данные в обоих случая в obj.

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

1. Запись конструктора будет длиннее.
2. Надо будет во всех функциях (имитирующих методы) использовать внутри этот указатель на структуру для доступа к полям (хотя в Питоне так и делают и никто особо не страдает).
3. Деструктор надо будет вызывать явно.
4. Придётся использовать указатели. При использовании классов они нужны не всегда.

Можно тоже писать без пробелов: meth(obj,arg1,arg2,…)

Можно. Про 25 < 26 я пошутил. Надо был смайлик поставить.

Я бы запилил нечто подобное в синтаксисе ЯП:

kennel.add(dog)
...

Iterator<Dog<::name>> it = kennel.iterator(Dog::name)
...

Dog<::name> entry = it.next()
print(entry)

Не знаю, нужно ли тебе сразу итерации по нескольким полям, но можно сделать так:

Iterator<> it = kennel.iterator(Dog::[name, sex])
Dog<::[name, sex]> entry = it.next()
print("${entry.name()}: ${entry.sex()}")

Изначально объект создаётся по классике. Но в хранилище он разбивается по твоему принципу. Ну, либо в самом ЯП нужно при создании добавлять тип хранения полей. Можно тоже в синтаксис это внедрить:

Dog:: dog = Dog::.new()

Array<Dog::> ...

тож вариант

впрочем!

в отсутствии jvm-филии

возникает очучение очередного извода плюсов ( для олдов pl/1 и algol-68) можно всё - мы за ценной не постоим

Если мы просто пишем отдельную функцию, то структура будет вся открыта на изменение кем попало

Если она не иммутабельная, конечно.

кста аспекты ща как в джава мире?

признаны ересью? али поглощены что и следов их отсутствия когда-то не осталось? али ...?

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

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

struct myObject *obj = createObj(...);
meth(obj, ...);

1. Разве?

auto with_class = new MyClass(arg1, arg2, ...);
auto wo_class = MyStruct(arg1, arg2, ...);

2. В паскале есть with, в лиспе with-slots.

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

4. А как можно сделать класс без указателя, если доступ к полю производится через указатель на объект + смещение? Если речь про то, что объект можно разместить на стеке, то для структуры тоже можно, если сделать конструктор, использующий alloca. Зато при добавлении поля в структуру в библиотеку не надо перекомпилировать программу, которая использует эту библиотеку.

3. … В gcc есть __attribute__((cleanup)). Можно деструктор указать при инициализации.

Обмазываются спрингом во все поля. Который аспектам обмазан с головы до ног. Но как там в сбере или амазоне я не в курсе. Знаю, что местный stevejobs из сбера тюхнул поседев от легаси спринга. А у меня свой путь, пользую свои фреймворки, работаю вообще в другой сфере, не разрабом. А будет время ещё и свой ООП ЯП запилю вместе с заинтересованным сообществом, чтобы всякие джавы с крестами и прочиями сями похоронить.

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

а зачем, если и так ЯП после пика C++ появилось уже так много, и они всё, что можно у условного рынка C++ уже отъели?

Ну, это как если бы ты был дорвейщиком/seo оптимизатором и спросил: Зачем нам gpt 3.5, мы и на байесовых алгоритмах неплохо ботаников из гугла опускаем. А оно вон как вышло.