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

Ответ на »сообщение 3741« (Trurl)
___________________________
Правда, все это несколько "размывается" передачей массивов как указателей (и без &, и без размерностей). Но определенный смысл помечать изменяемые аргументы в месте вызова есть (для читабельности).

Я был бы не против, чтобы язык требовал такое "помечание".
В целом, механизм возврата значений в Обероне весьма логичный. Он кажется "корявым" для тех, кто привык работать в терминах мат. функций. Но для "схемотехнической" идеологии Оберона все нормально.
Во-первых, есть две категории процедур: собственно процедуры (среди них - отдельная категория: команды, без параметров или с простыми параметрами, предназначенные для интерактивного вызова из среды - коммандером, кнопкой, меню и т.п.) и процедуры-функции с возвращаемым значением.
С последними все ясно - принято, что они не имеют побочного эффекта внутри и снаружи (все параметры функций - только по значению или по IN-ссылке). К сожалению, стандартом языка (в отличие от Ады) не запрещено описать функцию вида, например, Func (OUT retVal: INTEHGER): BOOLEAN - но на практике так никто не делает. С возвращаемыми значениями в Обероне описывают только чистые функции.

Процедуры же возвращают результат через VAR(OUT) параметры. И не надо кричать об их "нечистоте" - их смысл кардинально отличается от смысла функциий. Процедура (модуля или связанная с типом) - это разъем интерфейса, точка доступа к сервису, точка подключения к модулю/типу-микромодулю - суть такова.
У разъема есть "контакты", работающие для входных сигналов (значение, IN), для выходных (OUT) и на вход/выход (VAR). Переменные в точке вызова служат как бы "припоем" на подключении к разъему. Поэтому все логично и цельно.
Однако я бы не отказался, как уже сказал, видеть сразу и в точке вызова, какие переменные "подключены" на вход "разъема", а какие - на выход.

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

>>>Но определенный смысл помечать изменяемые аргументы в месте вызова есть (для читабельности).

Любопытно, однако, что в Си++ затем ввели передачу по ссылке, чтобы от этого избавиться. :)
Прежде всего, IMHO, для поддержки перегрузки операторов.

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

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

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

>>>Как закрыть этот самый дурацкий ETH Oberon и открыть собственно сам WinAOS, ради чего я всё это и скачивал?

Кажется, надо щелкнуть на
Configuration.DoCommands (Open Aos Display)
в окошке System3.Tool.
По крайней мере, вид сильно меняется. :)
Дальше пока не смотрел, но интересно.

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

Скорее всего это и правда наследие Си.
Ведь в Си нет передачи аргументов по ссылке, есть только передача по значению.
Поэтому передачу по ссылке приходится имитировать с помощью передачи адреса.

scanf("%f", &x);

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

Идея требовать указание способа передачи параметра при вызове, возможно, не лишена смысла (хотя, современная IDE и так покажет, что куда передаётся :-) ). Но в случае с C# это скорее дань уважения к си. Ведь параметры ссылочных типов (в частности массивы) не помечаются.

static void swap (ref int i,ref int j, int[] a)
{ int t = a[i];
  a[i]=a[j];
  a[j]=t; }
…
  swap (ref i, ref j, a);

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

Мдя... Закачал я WinAos, которым тут так восхищались, распаковал, запустил...
И опупел! Как такое возможно? Открылся тот самый ETH Oberon, в котором абсолютно невозможно работать, который абсолютно ничего не может открыть и запустить...
И вот это чудо(вище) занимает 101 мегабайт? На скриншотах выглядело гораздо симпатичнее...

Как закрыть этот самый дурацкий ETH Oberon и открыть собственно сам WinAOS, ради чего я всё это и скачивал?

Не огорчайтесь так. :)
Попробуем проконсультироваться у SAGE.

Мдя... Закачал я WinAos, которым тут так восхищались, распаковал, запустил...
И опупел! Как такое возможно? Открылся тот самый ETH Oberon, в котором абсолютно невозможно работать, который абсолютно ничего не может открыть и запустить...
И вот это чудо(вище) занимает 101 мегабайт? На скриншотах выглядело гораздо симпатичнее...

Как закрыть этот самый дурацкий ETH Oberon и открыть собственно сам WinAOS, ради чего я всё это и скачивал?

Да, ещё тут были утверждения когда-то, что в системе Оберон невозможны быги. Так вот, записывайте: открыл я какое-то окно, курсор мышки превратился в руку да таким и остался и обычным не стал - явный баг...

Ответ на »сообщение 3736« (Сергей Перовский)
___________________________

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

Нельзя ли пояснить эту мысль? Как я понимаю, мы постепенно вторгаемся в область Software Quality Assurance (SQA).

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

Реализация модуля в случае "горячей/холодной замены" должна гарантировать стабильность ранее заключенного контракта-интерфейса с клиентами. В противном случае потребуется его "переоформление/переподписание" с предварительным "уведомлением".

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

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

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

Ответ на »сообщение 3736« (Сергей Перовский)
___________________________

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

Известно, что всегда и во всем виноваты смежники. :)
Давайте не будем так драматизировать.
Есть очень простой пример "работы смежников": библиотеки.
Например, библиотеки для какого-нибудь ЯП.
Не всегда они бывают на высоте.
Я помню, как поразился утечкам памяти в Zortech C++ при использовании функции fseek.
Эта высокоинтеллектуальная функция "не любила" файловые буфера, и сразу обнуляла соответствующие указатели, как только управление попадало ей в лапы.
А т.к. сборки мусора в Си++ и тогда не было :) , то в результате, через некоторое время память исчерпывалась, и приходилось пользоваться буфером в 1 байт, с соответствующей скоростью.
Мда...
Но это все же исключение из правила, что библиотеки в целом достаточно надежны. :)