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

Я не понимаю, почему такое внимание уделяется перечислимому типу, весьма малозначительному элементу системы типов.


Только потому, что все хорошо представляют, что это такое, и проще показать на простых примерах его востребованность. Лично я не считаю отсутствие перечислимого типа самым страшным грехом оберона :) Отсутствие такого элемента скорее подчеркивает общую бедность и невыразительность.


ИМХО, гораздо интереснее и принципиальнее (старый уже) вопрос Сергея Перовского, что может дать Оберон программистам "традиционных" stand-alone приложений со статической линковкой.


Илья Ермаков упоминал о другом подходе к разработке (не отредактировал/скомпилировал/запустил), но подробнее не описал.


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

Сдается мне, что по такому критерию всех сделает какой-нибудь лисп ;)

Я не понимаю, почему такое внимание уделяется перечислимому типу, весьма малозначительному элементу системы типов.
Это чем-то напоминает басню Крылова: большое внимание букашкам, а "слона и не приметил".
(Кстати, я не согласен с тем, что перечислимый тип нельзя встроить в Оберон. В Зонноне Гуткнехт вернулся к перечислимому типу, а Зоннон все-таки язык обероновского семейства.)

ИМХО, гораздо интереснее и принципиальнее (старый уже) вопрос Сергея Перовского, что может дать Оберон программистам "традиционных" stand-alone приложений со статической линковкой.

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

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

Ответ на »сообщение 1420« (Владимир Лось)
___________________________

то кроме вас проверку на полноту охвата значений при проверке в switch организовать некому. Теперь вопрос: почему в этом аспекте остальные языки вас "кидают", а оберон – нет?...


Я тут проконсультировался у коллеги. Проблему в твоем примере с enum GCC и VC могут диагностировать на уровне предупреждений. Так что оберон со своими рантайм проверками пролетает по полной программе.

Ответ на »сообщение 1386« (Илья Ермаков)
___________________________
>>>В Компонентном Паскале есть полноценное наследование, точно такое же, как и в других ООП-языках.
Такая же холера, как в ветке по функциональному программированию :(
Стоит привести пример, где ФП неудобно, как тебе говорят - в лиспе(хаскеле и т.п.) можно писать императивно. Мы обсуждаем идеи или инструменты?

Я хочу сказать, что КОНЦЕПЦИИ компонентного и объектного программирования плохо совместимы. Если я реализую из модуля в модуль наследование по реализации, то о какой такой динамической перегрузке модулей может идти речь?
Когда для целей написания, трансляции и загрузки алгоритм делится на одни и те же куски, это может быть и изящно, но очень неудобно: пусть пишущие на Дельфи представят, что dll может содержать единственный unit.

Ответ на »сообщение 1420« (Владимир Лось)
___________________________


О том, что хотелось бы видеть в нормальном статически-типизированном языке.
Работайте на Фортране-IV... :о)


Причем здесь этот древний язык?


Теперь вопрос: почему в этом аспекте остальные языки вас "кидают", а оберон – нет?...


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

В такой switch всегда добавляется "default: ASSERT(false);". Ага, щаз! Так вам среднестатистическая "тётка" и понарасставит их по коду!!!


OK, оберон лучше подходит для стреднестатистических теток. Потому что перечислимые типы и прочие "сложные вещи" тетки все равно не оценят.


Сто лет ждите! Как раз для таких и нужно обероновское "битьё по шаловливым ручкам"... :о)


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

Ответ на »сообщение 1418« (pepper)
___________________________
Как говорил один мой препод: "... Не смотря на коньячок в синапсах... " :о)

О том, что хотелось бы видеть в нормальном статически-типизированном языке.
Работайте на Фортране-IV... :о)

Давайте поговорим о подобной поддержке, я не против. Глядишь и появится оберон-3. ... Я правильно понял, что от обсуждения конкретной "заморочки" в виде отсутствия в обероне перечислимого типа, ты пытаешься перейти к обсуждению оператора CASE?
Значения перечислимого типа в объявлении типа являются одновременно константами этого типа. Если общую поддержку синтаксиса вам предоставляет компилятор, то кроме вас проверку на полноту охвата значений при проверке в switch организовать некому. Теперь вопрос: почему в этом аспекте остальные языки вас "кидают", а оберон – нет?...
Смысл перечислимого типа не столько в использовании его значений в "квадратных скобках" после имён массивов, сколько в селекции веток действий по алгоритмам. Собственно, CASE для этого и служит. Но если в оберонах мы имеем "эмуляцию" перечисления через целые и компилятор, всё-таки, помогает нам "обратить внимание" на неполноту выбора, то почему в других "более правильных" языках, где, казалось бы, компилятору сам бог велел производить такие действия, этого нет? Тогда где "для реальности" больше подходящ образ действия компилятора и исполняющей среды? :о)

В такой switch всегда добавляется "default: ASSERT(false);".
Ага, щаз! Так вам среднестатистическая "тётка" и понарасставит их по коду!!! Сто лет ждите! Как раз для таких и нужно обероновское "битьё по шаловливым ручкам"... :о)

Но от поддержки со стороны компилятора я, естественно, не отказался бы.
То-то и оно...

Поясни пожалуйста, что значит "вылетит", если перечислимых типов в обероне нет?
Сам по себе принцип работы и поведения CASE не связан с наличием/отсутствием типа перечисления в языке.

Ответ на »сообщение 1414« (Владимир Лось)
___________________________

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


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


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


Давайте поговорим о подобной поддержке, я не против. Глядишь и появится оберон-3.


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

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


В такой switch всегда добавляется "default: ASSERT(false);". Но от поддержки со стороны компилятора я, естественно, не отказался бы.


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

Поясни пожалуйста, что значит "вылетит", если перечислимых типов в обероне нет?

P.S. Я правильно понял, что от обсуждения конкретной "заморочки" в виде отсутствия в обероне перечислимого типа, ты пытаешься перейти к обсуждению оператора CASE?

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

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

Точно. Настроение новогоднее, работать никто не хочет :)