>Чего реально нет на данный момент - это объектной операционной семантики. Но, собственно, на фиг она и не нужна.

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

> Вот плюсистам постоянно напоминают, что их недоязычек ни разу не ОО

Кто напоминает? Больные люди? Так больным людям следует укольчики поставить и рубашечки смирительные одеть, а слушать их не надо.

По критериям товарища Кея C++ вполне полноценный ОО-язык.

>> Об этом и речь - реализовать можно всё на всём, и _сама возможность_ реализации - ни разу не аргумент.

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

У меня другая специальность. Но я бы с интересом почитал об исследованиях, проведенных другими %)

>По критериям товарища Кея C++ вполне полноценный ОО-язык.

Принято считать, что смолтолк немного более, чем полностью ОО-трушнее, чем плюсы. И, если не затруднит, дайте ссылку на эти критерии.

Re^6: [vsl] формальная теория ООП

>>> Кроме того, то, что называют ООП, возможно покатило бы и в других местах. Как например насчет наследования автоматов (например путем расширения множества состояний) -- это будет ООП или ?

>> Ты очень хорошо проиллюстрировал мой тезис своим примером ;) Действительно, что угодно можно за уши или, в крайнем случае, за яйца, притянуть к ООП. А эффективно ли это будет? А насколько сложнее такой код будет потом поддерживать?

> Ты похоже меня не понял. Подумай о наследовании автоматов, и можно ли это назвать ООП.

Понял. И как раз про это и сказал: что угодно можно притянуть или назвать(как ты это сделал) ООП. Так и получается 90%.

> Принято считать, что смолтолк немного более, чем полностью ОО-трушнее, чем плюсы.

Мало ли что там кем принято. Смолтолк - чистый ОО-язык, C++ - мультипарадигмный язык, с поддержкой ОО в числе прочих моделей. Но поддержка эта полноценная.

> И, если не затруднит, дайте ссылку на эти критерии.

http://talklikeaduck.denhaven2.com/articles/2008/01/01/alan-kay-on-the-meanin...

Re^7: [vsl] формальная теория ООП

>> Ты похоже меня не понял. Подумай о наследовании автоматов, и можно ли это назвать ООП.

> Понял. И как раз про это и сказал: что угодно можно притянуть или назвать(как ты это сделал) ООП. Так и получается 90%.

Ну и далее: всегда ли это притягивание к ООП идёт на пользу и облегчает восприятие кода, пусть даже на сферично-вакуумном Ъ-оо языке?

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

И давно в C++ методы вызываются передачей сообщений? ( Это если по Кею) о_О

И как же его "я придумал термин 'объектно-ориентированный', и я не имел в виду C++"?

>По критериям товарища Кея C++ вполне полноценный ОО-язык.

цитату перепутал. я вот это высказывание имел в виду.

>> Ты похоже меня не понял. Подумай о наследовании автоматов, и можно ли это назвать ООП.

> Понял. И как раз про это и сказал: что угодно можно притянуть или назвать(как ты это сделал) ООП. Так и получается 90%.

А вот и не понял. Я не утверждаю, что наследование автоматов -- это ООП, тем более, что оно обратной вариантности к наследованию классов и полиморфизм там возможно отсутствует в обычном виде :-) Скорее это наследование + инкапсуляция.

Kay весьма рассплывчато и весьма подозрительно формулирует определение OOP.

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP.

>А всё, что есть в замыканиях, можно сделать через ООП. И всё, что есть в ООП, можно сделать в чистом Си. И что это доказывает?

Что все таки она вертится!

>Спрашивать надо у Буча. Можно и у Фаулера.

Буч слишком заумный чудак который сам себя обманул со своей методологие разработки. Фаулер слишком попсовый чудак - похож на священника-евангелиста. Ларман посередине между ними - его спрашивать надо.

Что же тут расплывчатого?

- messaging: наличие семантики "сообщений"

- local retention and protection: инкапсуляция и средства для ограничения доступа к потрохам объектов

- extreme late-binding of all things: грубо говоря, возможность подмены реализации объекта (с сохранением интерфейса), про которую знают другие модули, после компиляции или даже загрузки этих других модулей.

Да, критерии весьма общие, много кто в них попадает. Ну так ООП и есть общая и универсальная модель мышления, ага.

> Ларман посередине между ними - его спрашивать надо.

Конкретнее - как называется книга?

>Конкретнее - как называется книга?

Грейг Ларман "применение UML и шаблонов проектирования".

Там есть хороший раздел называющийся GRASP Patterns (ни у кого их больше не видел) - штука очень простая но значсительно более необходимая даже чем банда четырех. Та вообщто про простые вещи - но из обпыта работы и десятков собеседование я понял что они совсем не очевидные для многих.

Раздел про UML можно поскипать:)

> Грейг Ларман "применение UML и шаблонов проектирования".

Буэ-э-э...

>> Понял. И как раз про это и сказал: что угодно можно притянуть или назвать(как ты это сделал) ООП. Так и получается 90%.

> А вот и не понял. Я не утверждаю, что наследование автоматов -- это ООП, тем более, что оно обратной вариантности к наследованию классов и полиморфизм там возможно отсутствует в обычном виде :-) Скорее это наследование + инкапсуляция.

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

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

>Что нового привнёс именно ООП?

Вот мне и интересно, что ученые от CS могут сказать об определении ООП. Чтобы меньше было словоблудия.

//топикстартер

> Вот мне и интересно, что ученые от CS могут сказать об определении ООП.

Не очень много:

http://en.wikipedia.org/wiki/Object-oriented_programming#Formal_definition

> Чтобы меньше было словоблудия.

ООП - это метод, а не теория. А метод объяснить без "словоблудия" нереально. Возьми тот же ТРИЗ - тоже, вроде бы, простой метод, но чтоб научить им пользоваться адекватно, надо рассказать очень много всякого разного, основываясь на куче примеров.

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

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

> Что нового привнёс именно ООП?

Семантику (для формализации результатов объектного анализа) и методологию анализа.

> чтобы менеджер мог словоблудить

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

> И даже если ты найдёшь формальный способ притягивания автоматов к ООП, они работать лучше не станут.

Это не к тому, кого ты куращаешь, а к Пискунову претензии. Почитай его работу, он как раз пытается использовать автоматы для формализации операционной семантики ООП (по аналогии с тем, как строили в своё время Пи-исчисление).

>Вот мне и интересно, что ученые от CS могут сказать об определении ООП. Чтобы меньше было словоблудия.

ООП аналог астрологии :) к вычислительным наукам отношения не имеет

>и описание этих систем позволяет абстрагироваться от их содержания (реализации)

модель чёрного ящика ещё старее

>Эти требования в системном подходе не обязательны.

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

>Это беспрецедентный прорыв в качестве и скорости промышленной разработки ПО

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

качество - совокупность потребительских свойств. какие потребительские свойства разработки ПО?

>>Вот мне и интересно, что ученые от CS могут сказать об определении ООП. Чтобы меньше было словоблудия.

>ООП аналог астрологии :) к вычислительным наукам отношения не имеет

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

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

* почти все языки (чистый SQL не в счет)

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

Длина кода :-). Еще Бруксом было предложено, вполне успешно использовали в LOR-контесте :-).

> Это не к тому, кого ты куращаешь, а к Пискунову претензии. Почитай его работу, он как раз пытается использовать автоматы для формализации операционной семантики ООП (по аналогии с тем, как строили в своё время Пи-исчисление).

ЕМНИП, первыми использовать автоматы в ООА/ООП предложили Шлаер и Меллор. У них даже моделирующая система была на основе этого формализма.

> Длина кода :-). Еще Бруксом было предложено, вполне успешно использовали в LOR-контесте :-).

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

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

Функциональное программирование я положительно оцениваю не из-за минимизации нажатий на клавиши, а из-за того, что оно в ряде случаев:

1. Позволяет выразить в языке именно то, что я хотел сказать

2. Придает дополнительную гибкость, за которую можно платить длиной кода.

Напрмер, инициализация массива не в явном цикле, а подачей ему "инициализационной функции":

1. это то, что я имею в виду

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

> и поэтому создаст трудности при интеграции большого количества таких программ друг с другом.

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

> ЕМНИП, первыми использовать автоматы в ООА/ООП предложили Шлаер и Меллор.

По-моему так сказать: под ООА/ДП Шлеер и Меллор и понимали автоматы. :)

(Если не путаю, надо бы перечитать, но потерял бумажный вариант)