Надо сказать, что в существующей документации к BlackBox эти вопросы отражены довольно не внятно. Похоже Илье Ермакову надо писать очередную статью типа "Особенности ООП в Обероне/КП"

По поводу ООП в Обероне\КП. Обсуждение отсутствия конструкторов в КП оказалось неожиданно очень полезным (для меня). Раньше мне было непонятны "игры с фабриками", теперь все стало на свои места. Если говорить о собственно отсутствии конструкторов, то по моему вырисовывается такая картина:
1. Влюбом случае конкретные поля объекта нужно инициализирвоать руками, в соответствии с прикладной задачей, т.е. никто не "заставит" правильно их иницализировать.
2. Собственно КП как раз заставит, так как там приходится везде ставить ASSERT, отладчика то нет, в смысле пошагового, в смысле система отладки предполагает массированное использование ASSERT (во всяком случае родной код BlackBox ими нашпигован).
А если учесть еще и фабричные функции, то получается, что конструктор как средство надежности  поглощается другой совокупностью средств, которая, как мне кажется, в плане удобства и надежности дает гораздо больше.

Ответ на »сообщение 2823« (AVC)
___________________________
>>>что бы развито использовать ООП, его нужно использовать по определенным правилам, иначе надежности не будет...

>>>Разве это относится к Оберону, а не к самому ООП?

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

При всем уважении к Вирту ("Вы знаете, как я уважаю Остапа Ибрагимовича") его скептическое отношение к ООП определяется характером привычных ему задач.
Я уже говорил, что Оберон заточен не под решение сложных задач, а под построение сложных программных систем. Это разные (хотя и пересекающиеся) области.
Хотелось бы понять преимущества и недостатки модульного и объектного программирования в "зоне пересечения интересов" - там, где для решения сложной задачи потребуется создать сложную программную систему. Какие качества окажутся важнее, мне не ясно.
Например модель функционирования города (фирмы, страны) представляет собой такую задачу. Реализация в чистом ООП будет очень тяжелым делом, но я понимаю, с какого конца начинать и быстро напишу базовые классы. Я не понимаю, как подойти к такой задаче с позиций модульного программирования. Но это не значит, что этот подход невозможен и что он в конце концов не окажется проще.

Ответ на »сообщение 2819« (01)
___________________________

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


Разве это относится к Оберону, а не к самому ООП?

Ответ на »сообщение 2800« (Руслан Богатырев)
___________________________

У меня подчас складывается ощущение, как будто мы на рынке и перед нами стоит задача во что бы то ни стало продать товар под названием "Оберон". Кому и зачем? Я вообще считаю, что сторонники Оберона (и я в том числе) напрасно тратят время на бессмысленное убеждение в достоинствах Оберона и КП. Надо просто тихо использовать то, что нравится. А самим разобраться в нюансах можно и не на публике. Пользы будет больше. Как конкретным людям, так и для развития Оберонов.

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

Ответ на »сообщение 2805« (info21)
___________________________

Насчет конструкторов вроде была конкретная причина, чтобы исключить -- что-то насчет проблем с порядком вызова?

Можно об этом подробнее?
Я не в курсе.

Ответ на »сообщение 2818« (Антон Григорьев)
___________________________

Ответ на »сообщение 2813« (info21)
___________________________

>>>Тогда я вообще не понял, об чем речь.

Да речь всё о том же. Хоть AVC и пишет, что "выяснилось, что в них (конструкторах - А.Г.) нет особой нужды", меня пока убедить в этом не удалось. Потому что, во-первых, конструкторы синтаксически обязывают инициализировать объект только через них, а во-вторых, не запрещают наследование кода в других модулях.

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

вообщем последнее время при чтении ветки складывается такое пессимистическое впечатление:
первоначально было выстроено несколько громких тезисов относительно Оберона(у разных авторов) применительно к обучению программированию:
1 простота языка для изучения:
тут можно выделить несколько уровней

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

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

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

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

нет ни вузовских, ни школьных учебников по Оберону(КП), и как и чему учить неясно, если тому же, то зачем переходить непонятно, если новому, то как?

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

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

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

5 компактность
пожалуй единственное, что не вызывает сомнений))

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

Ответ на »сообщение 2813« (info21)
___________________________

Тогда я вообще не понял, об чем речь.

Да речь всё о том же. Хоть AVC и пишет, что "выяснилось, что в них (конструкторах - А.Г.) нет особой нужды", меня пока убедить в этом не удалось. Потому что, во-первых, конструкторы синтаксически обязывают инициализировать объект только через них, а во-вторых, не запрещают наследование кода в других модулях.

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

Вообще, хочу пояснить, зачем я задаю подобные вопросы. Мне нужно для своего личного использования делать какие-то выводы о том, чем хорош и чем плох тот или иной язык и/или подход. Так что меня интересуют не споры, а просто знакомство с чужим мнением. Мнение сторонников Оберона по поводу конструкторов было здесь изложено достаточно подробно, вряд ли вы сможете что-то добавить, я тоже более-менее всё сказал, а флудить, бесконечно повторяя одни и те же аргументы, я не хочу. Так что если ни у кого не осталось вопросов ко мне, готов прекратить обсуждение этой темы. То, что здесь было написано, дало мне возможность взглянуть на проблему с другой стороны, и за это всем большое спасибо - я действительно узнал много интересного, буду потихоньку осознавать :)