OberonCore
https://forum.oberoncore.ru/

"Типизированные константы"
https://forum.oberoncore.ru/viewtopic.php?f=22&t=1237
Страница 1 из 3

Автор:  bohdant [ Вторник, 04 Ноябрь, 2008 23:53 ]
Заголовок сообщения:  "Типизированные константы"

Подскажите, почему в АО отсутсвует конструкция вида?:
Код:
VAR
 a:LONGINT=5;

Автор:  igor [ Среда, 05 Ноябрь, 2008 09:36 ]
Заголовок сообщения:  Re: "Типизированные константы"

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

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

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

Автор:  bohdant [ Среда, 05 Ноябрь, 2008 10:19 ]
Заголовок сообщения:  Re: "Типизированные константы"

Цитата:
Этот вопрос следует расширить до:
2. Почему нет конструкторов массивов?
3. Почему нет конструкторов записей?


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

Цитата:
4. Почему результат функции может быть только базового типа?

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

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

Вот гляньте, на эти извращения:
Код:
PROCEDURE TableUS*(): LONGINT;
CODE {SYSTEM.i386}
   CALL L1
L1:
   POP EAX
   ADD EAX,8
   POP EBP
   RET
      (* alphabet *)
   DB 1EX, "a", "A", 4X,   30X, "b", "B", 4X,   2EX, "c", "C", 4X,   20X, "d", "D", 4X
   DB 12X, "e", "E", 4X,   21X, "f", "F", 4X,   22X, "g", "G", 4X,   23X, "h", "H", 4X
   DB 17X, "i", "I", 4X,   24X, "j", "J", 4X,   25X, "k", "K", 4X,   26X, "l", "L", 4X
   DB 32X, "m", "M", 4X,   31X, "n", "N", 4X,   18X, "o", "O", 4X,   19X, "p", "P", 4X
   DB 10X, "q", "Q", 4X,   13X, "r", "R", 4X,   1FX, "s", "S", 4X,   14X, "t", "T", 4X
   DB 16X, "u", "U", 4X,   2FX, "v", "V", 4X,   11X, "w", "W", 4X,   2DX, "x", "X", 4X
   DB 15X, "y", "Y", 4X,   2CX, "z", "Z", 4X

Автор:  igor [ Среда, 05 Ноябрь, 2008 10:55 ]
Заголовок сообщения:  Re: "Типизированные константы"

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

Если разрешить типизированные константы, то что помешает программисту написать:
Код:
TYPE MyRec = RECORD <куча полей> END;
CONST rec: MyRec = <???> (* конструкторов-то нет! *)
Тут я могу согласиться с тем, что нет конструкторов записей. Как, например, быть с методами, которые наравне с полями связаны с типом записей. Но по поводу конструкторов массивов внутренне не могу согласиться с их отсутствием. Почему Н. Вирт их убрал? Если они и приносят какое-то "зло", то их "добро" всё-таки перевешивает.
bohdant писал(а):
Вот гляньте, на эти извращения
Слово "извращения" подобрано очень точно :wink:

Автор:  Valery Solovey [ Среда, 05 Ноябрь, 2008 11:31 ]
Заголовок сообщения:  Re: "Типизированные константы"

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

Автор:  igor [ Среда, 05 Ноябрь, 2008 11:51 ]
Заголовок сообщения:  Re: "Типизированные константы"

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

Автор:  Info21 [ Среда, 05 Ноябрь, 2008 11:55 ]
Заголовок сообщения:  Re: "Типизированные константы"

Игорь Лоскутов писал(а):
... по поводу конструкторов массивов внутренне не могу согласиться с их отсутствием. Почему Н. Вирт их убрал? Если они и приносят какое-то "зло", то их "добро" всё-таки перевешивает.

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

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

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

Автор:  igor [ Среда, 05 Ноябрь, 2008 12:24 ]
Заголовок сообщения:  Re: "Типизированные константы"

Вот простой эфемерный (я его не делал) примерчик. Допустим, мы пишем игрушку-аркаду на тему колобка в лабиринте. Игровая карта представляет собой матрицу 20х30 квадратных полей. Каждое поле может иметь одно из трёх значений: "Стена", "Пустое свободное пространство" и "Свободное пространство с артефактом". Более менее сурьёзная игрушка должна иметь несколько уровней :) . Уровни отличаются друг от друга только игровой картой. Если бы были возможны конструкторы множеств, то я бы написал:
Код:
TYPE Map* = ARRAY 30, 20 OF BYTE; (* 0: wall; 1: empty; 2: artefact *)
CONST
  Level1*:Map = ((0, 0, 0, 1, 1, 1, 0, ...1),
                         ................................
                         (0, 0, 1, 3, 1, 0, 0, ...0));
  Level2* ..... (* и так далее, все 10 уровней *)
Отметим наглядность кода (особенно в случае использования моноширинного шрифта) и лаконичность. Игровую карту можно буквально лицезреть в коде. А как удобно её создавать.
А во что это превращается в оберонах?

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

Автор:  Geniepro [ Среда, 05 Ноябрь, 2008 12:51 ]
Заголовок сообщения:  Re: "Типизированные константы"

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

Автор:  bohdant [ Среда, 05 Ноябрь, 2008 13:05 ]
Заголовок сообщения:  Re: "Типизированные константы"

Игорь Лоскутов писал(а):
В Вашем посте есть противоречие, которое я не задумываясь истрактовал произвольным образом

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

100%
Цитата:
Но по поводу конструкторов массивов внутренне не могу согласиться с их отсутствием. Почему Н. Вирт их убрал? Если они и приносят какое-то "зло", то их "добро" всё-таки перевешивает.

100%
Info21 писал(а):
Он их не "убрал", а "не добавил".
Потому что это не является средством абсолютно необходимым.

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

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

Я вот почему спросил, потому, что хочу вернуть эту фичу в язык. На счет "усложнение компилятора" поговорим, когда будет работать ;)
Цитата:
Много раз уже про это ключевое для дизайна Оберонов положение говорили.

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

Автор:  Ярослав Романченко [ Среда, 05 Ноябрь, 2008 13:15 ]
Заголовок сообщения:  Re: "Типизированные константы"

Geniepro писал(а):
Вся-таки лучше такие карты хранить в отдельном от кода файле, что бы легко редактировать специальным редактором карт, например.
Сам себе поражаюсь, но я с Вами в данном случае согласен на все 100% :D

Автор:  Comdiv [ Среда, 05 Ноябрь, 2008 13:26 ]
Заголовок сообщения:  Re: "Типизированные константы"

bohdant писал(а):
Подскажите, почему в АО отсутсвует конструкция вида?:
Код:
VAR
 a:LONGINT=5;


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

Автор:  Иван Кузьмицкий [ Среда, 05 Ноябрь, 2008 14:16 ]
Заголовок сообщения:  Re: "Типизированные константы"

Игорь Лоскутов писал(а):
Отметим наглядность кода (особенно в случае использования моноширинного шрифта) и лаконичность. Игровую карту можно буквально лицезреть в коде. А как удобно её создавать.
А во что это превращается в оберонах?

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


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

Автор:  igor [ Среда, 05 Ноябрь, 2008 15:22 ]
Заголовок сообщения:  Re: "Типизированные константы"

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

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

Автор:  Ярослав Романченко [ Среда, 05 Ноябрь, 2008 15:36 ]
Заголовок сообщения:  Re: "Типизированные константы"

Игорь Лоскутов писал(а):
Кстати, о ресурсах.
Моё ИМХО, ресурсы тоже лучше выносить в файлы... XML например.

Автор:  igor [ Среда, 05 Ноябрь, 2008 15:37 ]
Заголовок сообщения:  Re: "Типизированные константы"

bohdant писал(а):
Игорь Лоскутов писал(а):
В Вашем посте есть противоречие, которое я не задумываясь истрактовал произвольным образом


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

Автор:  Евгений Темиргалеев [ Среда, 05 Ноябрь, 2008 15:40 ]
Заголовок сообщения:  Re: "Типизированные константы"

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

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

Автор:  igor [ Среда, 05 Ноябрь, 2008 15:44 ]
Заголовок сообщения:  Re: "Типизированные константы"

Ярослав Романченко писал(а):
Моё ИМХО, ресурсы тоже лучше выносить в файлы... XML например.
И хранить там ресурсы в виде моделей и вьюшек :wink: Не зря же они потомки Store.

Автор:  igor [ Среда, 05 Ноябрь, 2008 18:50 ]
Заголовок сообщения:  Re: "Типизированные константы"

Евгений Темиргалеев писал(а):
Вы вполне можете набрать карту в том же тексте, что и текст модуля. После коммандера:
Код:
^Q GameMain.Start
0 0 0 0 1 1 0 2
0 0 ...
~
И все Ваши требования реализованы, плюс ещё карту можно менять без перекомпиляции и перезагрузки модуля. Этот момент вполне оправдывает затраты на написание нескольких строк по чтению данных в массив, имхо.
Интересное предложение :roll: Не хочу показаться привередливым, но по моему личному убеждению, в коде не должно быть ничего, кроме голого текста. Я не признаю даже форматирование, не говоря уже про складки, командеры и прочее. То есть форматирование может быть, но оно должно быть (ИМХО) встроено в редактор кода, а не в саму текстовую модель.
Евгений Темиргалеев писал(а):
Вы не совсем понимаете ситуацию. Это не расширение языка, это текст с описанием меню. В том формате, который придумали и который понимает построитель меню. Мы правим текст с описанием меню и на лету получаем новое меню. А если бы оно было зашито в коде, то: правка кода/перекомпиляция/перезагрузка ББ или как минимум модуля с "описанием". А как быть с тем что у каждой подсистемы свое меню и подсистемы могут добавляться на лету?
Так, давайте разбираться вместе. "... это текст с описанием ..." Описание делают на каком-либо языке. На каком, в данном случае? На русском? Нет. На КП? Нет... Правильно, на некотором формальном языке. И раз мне приходится его знать и применять для того, чтобы получить работоспособную программу, то его можно рассматривать как расширение основного языка.

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

Автор:  Valery Solovey [ Среда, 05 Ноябрь, 2008 19:18 ]
Заголовок сообщения:  Re: "Типизированные константы"

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

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

Страница 1 из 3 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/