OberonCore

Подскажите, почему в АО отсутсвует конструкция вида?:

Этот вопрос следует расширить до:
2. Почему нет конструкторов массивов?
3. Почему нет конструкторов записей?
4. Почему результат функции может быть только базового типа?
Возможно, что ответ на все эти вопросы, включая первый, будет один.

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

PS2 Кстати, конструктор множества остался, видимо, потому что в обероне множество -- это базовый тип.

В JPI-Modula-2 конструкторы были, приятно было с ними работать.


Затем, что бы код нормальный генерился.

Ответ:"особенность перекочевала в него из других оберонов" - не принимаю.

Вот гляньте, на эти извращения:

В Вашем посте есть противоречие, которое я не задумываясь истрактовал произвольным образом . О чём всё-таки идёт речь: о типизированных константах (см. тему) или об инициализации переменных (см. код)?

Если разрешить типизированные константы, то что помешает программисту написать: Тут я могу согласиться с тем, что нет конструкторов записей. Как, например, быть с методами, которые наравне с полями связаны с типом записей. Но по поводу конструкторов массивов внутренне не могу согласиться с их отсутствием. Почему Н. Вирт их убрал? Если они и приносят какое-то "зло", то их "добро" всё-таки перевешивает.
Слово "извращения" подобрано очень точно

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

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

Он их не "убрал", а "не добавил".
Потому что это не является средством абсолютно необходимым.

Относительная оценка
"добра" (здесь: пусть миллископическое удобство, хотя в моем, например, опыте оно вообще инфинитезимальное)
и "зла" (усложнение компилятора)
-- вещь сильно субъективная,
и сильно зависит от временного горизонта планирования
И от остроты ощущения непредсказуемости будущего уже на горизонте 10 лет.
Сумел бы кто-нибудь предсказать в 1998 ход жизни до 2008? Смешно же...

Много раз уже про это ключевое для дизайна Оберонов положение говорили.

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

PS Не смотря ни на что, я выбираю КП (т. е. один из оберонов)

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

Да, я рассплывчато назвал... Извиняюсь Речь идет "об инициализации переменных"

100%

100%

Судя по моему опыту, вещь архи необходимая!
Я добавлю, что не всегда можно массив инитить из файла(случай с МК)!

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

Я вот почему спросил, потому, что хочу вернуть эту фичу в язык. На счет "усложнение компилятора" поговорим, когда будет работать

Вопрос, Вы смотрели http://www.inf.ethz.ch/personal/wirth/Articles/Miscellaneous/PICL.pdf?
Чо там с Обероном натворили??? Чо хотели, то и делали... А почему? Да потому, что как и у нас, нужен дисер, будет теория... Кому нужно, да никому

Сам себе поражаюсь, но я с Вами в данном случае согласен на все 100%

Чуть попозже я расскажу, почему такой штуки нет в Обероне. А сейчас просто не хватает времени по причине завала на работе (при чём именно из-за того, что такая штука есть в Java).

В мало-мальски серьёзных игрушках, описания ресурсов выносятся из исходного текста. Например, выносятся в XML. Сужу по собственному опыту - конструктор массивов использовал очень редко.

Согласен со всеми, кто говорит, что такие вещи лучше выносить в отдельный файл и делать редактор карт.
В конкретном примере, который я привёл, это будет правильным решением.

Кстати, о ресурсах. Мне никогда не нравилось то, что для описания ресурсов приходится использовать другой язык. Взять тот же Блэкбокс, такой ресурс как меню, например. В КП нет ключевого слова "MENU". То есть используется какое-то нестандартное расширение языка, которое неизвестно в какую сторону "сыграет" в будущем. А в том варианте, который я привёл, всё реализовано на "родном" языке.

Моё ИМХО, ресурсы тоже лучше выносить в файлы... XML например.

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

Вы вполне можете набрать карту в том же тексте, что и текст модуля. После коммандера:И все Ваши требования реализованы, плюс ещё карту можно менять без перекомпиляции и перезагрузки модуля. Этот момент вполне оправдывает затраты на написание нескольких строк по чтению данных в массив, имхо. Как читать: см DevCommanders.Par, TextMappers.Scanner (scanner.ConnectTo(DevCommanders.par.text))

Вы не совсем понимаете ситуацию. Это не расширение языка, это текст с описанием меню. В том формате, который придумали и который понимает построитель меню. Мы правим текст с описанием меню и на лету получаем новое меню. А если бы оно было зашито в коде, то: правка кода/перекомпиляция/перезагрузка ББ или как минимум модуля с "описанием". А как быть с тем что у каждой подсистемы свое меню и подсистемы могут добавляться на лету?

И хранить там ресурсы в виде моделей и вьюшек Не зря же они потомки Store.

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

PS Называть вещи своими именами -- это моё хобби

Что Вы подразумеваете под форматированием? Если Вы где-то в тексте поставили (или не поставили) возврат каретки, то это тоже фроматирование.Вам не надо получать программу. Это не программа, а обычный документ, такой же, как исходный код модуля или его документация в соседней директории.

Но Ваш комментарий относился к необязательной необходимости самого языка? На это тоже есть ответ. Форматирование средствами КП трудоёмко как для человека, составляющего меню, так и для каркаса, читающего его время от времени. Поэтому, я думаю, и был выбран специальный формат меню.