Ну ты сказал что в ООП нет объектов

я сказал что "ООП не про объекты"

а не "там нет объектов"

гениально

если ООП не про объекты, то логично предположить, что их там не должно быть?

Однако, они там есть почему-то

гениально

не логично

давай так

ну у тебя проблемы с логикой

вот есть у тебя в языке классы

но в аббривиатуре "ооп" их нет

следовательно классов быть не должно?

или это просто способ добиться чего-то что есть в аббривиатуре?

лол

в аббревиатуре много чего нет

речь сейчас не про нее

давай тогда сначала

что для тебя ООП

как отличить "ооп" от "не ооп"

под "объектами" тут можно понимать что угодно. Какие-то штуки обмениваются сообщениями. точка.

Почему тогда это именно сообщения, а не "какие-то" штуки? Как отличить сообщение от "какой-то" штуки?

что для тебя ООП

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

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

под твое определение подходит хаскель

p.s. языки программирования за последние 30 лет не особо развились. Компиляторы - возможно (rust например)

как отличить "ооп" от "не ооп"

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

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

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

с наследованием, классами и всем вытекающим

с наследованием, классами и всем вытекающим

зачем нам наследование, классы и все вытекающее? что при помощи них ты хочешь добиться?

p.s. языки программирования за последние 30 лет не особо развились. Компиляторы - возможно (rust например)

golang вполне развитие, выкинули кучу ненужного )

ну то есть вот есть старое доброе процедурное программирование, где данные лежат там, а поведение тут. И поведение берет данные, и что-то с ними делает.

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

golang вполне развитие, выкинули кучу ненужного )

если ты приглядишься, там ничего нового нет

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

сливаешься типа?)

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

если ты приглядишься, там ничего нового нет

так это хорошо, взяли основное и фич не добавили

Так ведется допрос, которым ты меня пытаешься запутать

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

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

потому что если я тебе буду говорить - то ты будешь "лалка ооп это не то я так не привык"

Ну я человек не глупый, ты объясни, почему ООП не про объекты то

Привести? То есть ответа у тебя нет, просто давайте походим вокруг до чего-нибудь, что назовём ответом?

а если ты будешь сам думать - то сам и додумаешься до сути

фига я вбросил

Ну я человек не глупый, ты объясни, почему ООП не про объекты то

блин я и объясняю. Объекты - это вещи. А ООП объясняет как эти вещи должны между собой взаимодействовать.

Ну в этом я с тобой согласен

то есть если ты возьмешь "объекты" и будешь работать с ними без late binding и без messagin ты получишь просто данные и процедуры

тут есть очень простая грань

Но если ООП объясняет взаимодействие объектов, то почему ООП не про объекты?)

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

по сути ООП это подвид структурного программирования

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

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

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

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

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

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

блин это надо метафору по понятнее придумать

я понял твою мысль

объекты - это абстракция

у них куча реализаций

потому лучше вообще их не учитывать в контексте ООП

Ладно, ладно

Привели пример ООП без объектов, так лучше

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

Привели пример ООП без объектов, так лучше

вот да

Привели пример ООП без объектов, так лучше

вы издеваетесь?

Почему

😆

ну... в любом случае я уже приводил - erlang

Я не издеваюсь, проглядел

чет я не вижу, где у эрланга ооп

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

чет я не вижу, где у эрланга ооп

потому что повторюсь - ООП не про объекты)

блин где-то была цитата

Эм. Хорошо, в элранге нет объектов. Что обменивается сообщениями?

Эм. Хорошо, в элранге нет объектов. Что обменивается сообщениями?

микротреды

Вообще я тебя понял, твоё понимание ООП отличается от .. Распространенного, что ли

не совсем

Т.е. данные там лежат в полях, которые в функции, которая в треде?

Т.е. данные там лежат в полях, которые в функции, которая в треде?

не совсем, у тебя есть одна какая-то хрень которая хранит данные и код, обрабатывающий эти данные.

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

Вообще я тебя понял, твоё понимание ООП отличается от .. Распространенного, что ли

другая штука. Распространенное понимание ООП - отсутствие понимания вовсе)

ебашим процедуры завернутые в классы и норм

Уже лучше. Т.е. есть структура, которая хранит не только данные, но и код взаимодействия с этими данными, и мы в рантайме можем изменить этот код и будет иначе работа вестись?