Ответ на »сообщение 1412« (Alexey Veselovsky)
___________________________


Ну, во-первых тут шаблоны вовсе не обязательны.


Необязательны. Просто обсуждение плавно перетекло от перечислимого типа к типизирпованному целому.


Во-вторых проектирование, написание и использование шаблонов требует таки бОльших усилий (и знаний).  Прежде чем написать вот такую вот конструкию, ведь шаблон надо написать, отладить и т.д. и т.п.


Во-первых, никто не говорил, что C++ легок для изучения. Во-вторых, есть более другие языки, с более человеческим метапрограммированием, но оберон все равно к ним не относится.

Ответ на »сообщение 1406« (Geniepro)
___________________________
я здесь не претендовал на ФП. Closures, например, вполне естественная и даже неотемлемая часть такого ОО языка как смолток (кстати, о простоте - всего 6 ключевых строк) - все есть объект, даже блок кода.

Дяденьки, куда вас всех хором несёть? Какие удобства объявлений?, какая параметризация?, какая равноценность типов, объявленных пользователем типам, предопределённым в языке? Вы об чём ваще?

Чем ценно объявление типа перечисление "само-по-себе"? Да – ничем. Если только нет поддержки в компиляторе при манипулировании со значениями этого типа.

Скорми любому компилятору Си (да и Джаве, скорее всего, следующее:...

enum {aaa,bbb,ccc,ddd} my_enum;
...
switch(my_enum)
{
  case aaa: ... ; break;
  case bbb: ... ; break;
}

... компилятор это "сглотнёть" не поперхнётся.
Мало того, что нас при компиляции не известят, что мы не правы, так ещё и при выполнении никаких неприятностей не случиться...
А между тем здесь заложена кардинальная ошибка. Если мы выбираем нечто из диапазона значений, то мы ОБЯЗАНЫ текстуально обозначить нашу реакцию на ЛЮБОЕ из значений типа. Беда в том, что "самый-самый" Си – не язык поддержки проектов, а язык записи кода. Он "полностью доверяет" программисту. Ещё большая беда - в том, что оние программисты не все читали умные книжки в своё время, а всё больше обучались "фолькльорно-вербальным" способом...
А что сделает любой из "недоразвитых" оберонов? "Вылетит" с исключением. Просто потому, что в нём сама конструкция оператора выбора не оставлена "как особая, удобная форма записи оператора IF", а проработана для ПОДДЕРЖКИ ПРОЕКТНЫХ РЕШЕНИЙ. И эта опция НЕ ОТКЛЮЧАЕМА ПРИНЦИПИАЛЬНО.

Та-ак, друзья-оберонщики... в кои-то веки посетил сей форум и вижу, что у нас тут очередное "обострение" :) Видать к Новому году дело....

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

Ответ на »сообщение 1403« (Alexey Veselovsky)
___________________________
Хотя нет, не проще - так же.

Проще и нагляднее будет как раз на C++. Что-то типа:


typedef typed_int<struct color_tag> Color;


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

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

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

Стоит ли оно того? Не знаю... Где-то возможно и стоит, но в большенстве случаев - пожалуй нет.

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

Ответ на »сообщение 1409« (Jean)
___________________________
Дамс, а я-то думал, что приведённый в MSDN пример использования оператора goto в С#

switch (n)
{
    case 1:  cost += 25; break;

    case 2:  cost += 25; goto case 1;

    case 3:  cost += 50; goto case 1;

    default: Console.WriteLine("Invalid selection."); break;
}

писали какие-то маразматики, оказывается - это ещё невинные шалости, по сравнению с приведённым Вами кодом!

Мне лично шедевр Тома Даффа даже в кошмаре присниться не мог! :о))

Приходится иногда вставлять тот же goto, но что бы ТАК извращаться с case...
Забавно, Borland C++ 3.1 действительно без проблем сжевал этот код Тома Даффа. Хорошо хоть в C# он уже невалиден... :о))

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

>>>Проще и нагляднее будет как раз на C++. Что-то типа:
>>>typedef typed_int<struct color_tag> Color;

Вот это именно то, что я давно подозревал!
Вот она - граница между двумя "мирами".
То, что Вы называете "проще и нагляднее" для меня "синтаксический бред".


Это пример типизированного int'а. Если для тебя это сложно - можно вернуться к обычному enum.


А решение на Обероне, которое для Вас представляется "сложным и ненаглядным", мне видится почти как текст на "родном" языке с легким английским акцентом :).


Оно не сложное. Оно громоздкое и неудобное в использовании. Такой же громоздкий и неудобный "оберновский" аналог на С++ будет выглядеть как:

struct Color{ int value; };

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


Приведу цитату прямо из сети, она небольшая.


За такой код в нормальных конторах увольняют. Причем здесь язык?

>>>Проще и нагляднее будет как раз на C++. Что-то типа:
>>>typedef typed_int<struct color_tag> Color;

Вот это именно то, что я давно подозревал!
Вот она - граница между двумя "мирами".
То, что Вы называете "проще и нагляднее" для меня "синтаксический бред". А решение на Обероне, которое для Вас представляется "сложным и ненаглядным", мне видится почти как текст на "родном" языке с легким английским акцентом :).
Я понимаю, что простота и наглядность это вещи субъективные.
Но все же... Только в С/С++ возможны такие вещи, которые принято называть "синтаксическим ужасом".
Приведу цитату прямо из сети, она небольшая.
http://itc.ua/article.phtml?ID=22622&IDw=33&pid=52
--------------------------------------------------
switch (len % 8) {
  case 0: {
    do { HAL_IO_PORT = *pSource++;
      case 7: { HAL_IO_PORT = *pSource++; }
      ...
      case 1: { HAL_IO_PORT = *pSource++; }
    } while (--n > 0);
  }
}
"Для понимания, что это – натуральный ужас, вам вовсе не надо знать C++ или С. Просто следите за соблюдением правила вложенности блоков. Видите? Блоки, которые, по логике вещей, должны быть на одном уровне иерархии (они начинаются со слова case), почему-то на одном уровне не находятся. И между тем это совершенно законный работающий код на С++. Более того, в C++ законность работоспособности данного кода унаследована от C. Именно на C этот великолепный кошмар был изобретен 9 ноября 1983 г. (кстати, еще один юбилей!) программистом Томом Даффом. Для подтверждения законности этого кода в свое время потребовалось личное участие Ларри Рослера, председателя подкомитета ANSI по стандартизации языка C" - конец цитаты.
No comment.

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

>>>Предлагаю готовить "мирный договор" :))
Ура!
А то аргументы в этой ветке повторяются с каждым новым участником.
Предлагаю компромисные ответы на некоторые прозвучавшие тут вопросы :)

Предлагаю сделать FAQ по Оберону и его отличиям и достоинствам и вывесить прямо на городских воротах при въезде в Королевство! ;о)

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

Нет, closures в Обероне нет.
Впрочем, как и нужды в них, т.к. есть объекты.

объекты - closures для бедных!
closures - объекты для бедных!

Да здравствует просветление! :о))