OberonCore

Что же там непонятного? Ах, ну мы ж в ББ не работали, стандартных средств документного интерфейса не знаем. Но всё время пытаемся доказать, что уж вот этого-то сделать там нельзя. Можно. Любая инфраструктура для длительной работы над своими задачами делается с песней, с применением уже данных готовых кубиков... А готовых чудо-средств на якобы все случаи жизни (кривых обобщений, т.е., с которыми обычно помучаешься - а потом плюнешь и всё равно делаешь своё) никто, конечно, не закладывал.

А Вы не заметили как сменилось несколько поколений Windows и легион версий мейнстрим сред разработки, а Обероны здравствуют.
А всё потому-что они не связаны так жестко с host системой (каждая Оберон система фактически представляет собой ОС со своим рантаймом), как связаны мейнстрим среды разработки. Мейнстрим среды при смене поколений Windows просто тихо умирают. Вновь появляющиеся версии практически не улучшенные версии старых сред, а зачастую полностью переписанные новые версии.

А что не так с этим методом? Он предусмотрен во фреймворке .NET изначально, вручную его добавлять для каждого типа не нужно, просто переопределяете готовую заготовку и всё! Это вполне в духе .NET'а... "Базовых типов" в .NET'е просто нет -- всё объект...

Ага, присмотритесь хотя бы к этой строке:

Ну и где взять все эти Rocot-модули? А без них нихрена-то и непонятно, где там что у Вас и как реализовано...

Камрад, модули совсем рядом лежат. Фактически в той же самой подсистеме. Вы разве не знали?

Боюсь, в моей поставке блэкбокса нет никакой подсистемы Rocot... И вообще ни одного файла, начинающегося на Rocot...

Если бы они были нужны для понимания основного смысла, я бы их привёл. RocotStructs - древовидные структуры, интерфейс которых был приведён. Text + BCF - обёртка над стандартными текстами ББ, для независимости от Framewrok при написании трансляторов. Я Вам показал, как формируется интерактивное представление произвольной динамической структуры данных и его открытие пользователю в новом документе. Я не виноват, если ваш .NET или Питон вообще ни сном ни духом о таком понятии, как документ

А язык-то тут причём? Этот вопрос относится только к наличию\отсутствию готовых наработок. Мы же про языки говорим, а не про заранее предусмотренные методы.

Да. Это уже будет проблема программиста. Как и в С++, где, так же, вообще можно не написать return или допустить, что не в любом случае результат будет определён -- и не узнать об этом никогда. Вот пример, как язык влияет на количество ошибок в итоговом коде.
Это вполне в духе С/C++. Все называть функциями, с целым результатом по умолчанию, и везде этот результат игнорировать. (Очень хорошо это заметно, когда в ББ с WinApi приходится работать и писать вроде res := WinApi.Beep(...))

В духе Оберона - программирования по контракту с пред/пост условиями. Если при выполнении процедуры возможна ошибка, тот кто её пишет, предусмотрит способ сообщить о ней. О тот кто использует, должен соот-но прореагировать. И Обероновский код, на который мы смотрим как на пример, учит этому.
Да, качество кода как и везде, зависит от того кто пишет. Однако строгий дух Оберона дисциплинирует мышление и на примере других учишься думать и писать как следует. А гигантские C++/С#/Java и иже с ними нихрена не дисциплинируют - пиши бездумно что хошь и как хошь, компилер все проглотит. Только потом либо писатель будет сидеть на дебугере, либо у проца будет несварение от многочисленных IF a.ToString().Length() = 4...

Вы имеете в виду что-то типа Active Documents?
Ну, положим для С++ и MFC что-то такое имеется. Правда, я этой проблемой пока не интересовался (не было надобности в этих активных документах), но, судя по поверхностному взгляду, их вполне можно прикрутить и к .NET'у...

То есть всякие там "базовые типы" к самомму языку отношения не имеют?
Тогда к чему вообще был весь этот сыр-бор с наличием-отсутствием методов у целых чисел?

Я имею в виду составные, активные документы. Которые полноценно не реализованы практически нигде, кроме Оберон-систем. Другие попытки либо неполноценные, либо не дожили до сегодняшних дней, либо совсем малоизвестны (ну, в Смоллтоках такое, видимо, есть). Понятие активного текстового интерфейса вообще характерно для европейской школы, американский подход всё вон детскими пиктограммами мыслит... Вообще, ещё Раскина "Интерфейс" почитайте на эту тему. И Пфистера "Компонентное ПО" http://oberoncore.ru/index.php?option=c ... &Itemid=10

В языке введен тип "число". Если мне нужен объект - я сооружу объект с методами. Зрение остаётся чёткое - вот число, вот объект. То, что какая-то коммерческая контора с какого-то перепугу приняла число за объект и выдаёт это за "хорошо", аргументом, имхо, не является.

Нет, Иван, Вы немного не правы.
"число" - есть тоже объект. Просто все "методы" этого класса уже реализованы АЖ на уровне исполняющей машины. Вы и говорите-то о "числах", как об "объектах" так легко, просто потому, что этот тип сущностей уже до чёртиков проработан и обсосан, вплоть до реализаций в кремнии... Это - именно базовый тип. Базовей не бывает. Вплоть до использования в основе абстракций типа "адрес", "смещение", "целое"...
В Смолтоке следование изначальным постулатам более чёткое и без "уклонистов". Там вполне естественно "числу" посылать сообщение "цикл" или "сложить_с". Другое дело, что реализации часто (для эффективности) реализуют не рекурсивно и не на самом смолтоке, а нативными операциями процессора...

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

Есть и ещё хороший критерий "объект" - "не объект", кроме активности-пассивности. Если сущность имеет идентичность (т.е. индивидуальность) - то объект. Если нет - то просто данные. Мне нет разницы "вот это число 5" и "вон то число 5". И посылать им сообщения я не собираюсь

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

Microsoft достаточно последовательна, и редко перетряхивает API. Вот и весь секрет выживаемости Оберонов.
Из описания истории ББ: впервые он появился под Win 3.1. Портирование на Win95 прошло достаточно безболезненно (кстати, гуй у ББ несильно изменился, и становится понятным, откуда взялся "корявый" statusbar , который эмулирует edit, отсутствие toolbar'а). Следующие версии Windows ББ пережил благополучно. Спасибо Microsoft. А ведь могла бы сломать API.

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

Для меня основной положительный эффект от такой глобально субтипизации - это пржде всего самодокументирование кода. Т.е., то, во что отказывается верить Пётр - при таком подходе я могу обходится без документации, комментариев и не заглядывания в имлементацию.

Другой большой положительный эффект - я могу смелее рефакторить существующий код. Например, я объединяю две имплементации таблиц (пришли с разных платформ). В одной имплементации колонки нумеровались с 0, а в другой - с 1. Есть куча существующего "рабочего" кода, который использует эти имплементации, тестами он нифига не покрыт, как он работает никто не знает, потому что он древний как гавно мамонта (только прошу, не надо рассказывать сказки, что такого в оберонах не бывает). Из интерфейса новой имплементации выкидываются целые и вместо них появляются нормальные типы данных - "колонки" и "строки" (а попутно выкидываюься ненужные теперь ассерты типа того, что колонка не может быть меньше 1 или 0). Все. Все места, где надо с умом преобразовать старое в новое - как на ладони.

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



Нормальные компиляторы C++ такое не пропускают.



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



Это в духе C, но не C++. В С++ есть исключения, они позволяют избежать возращения "мусора" в принципе.



Я вас огорчу. В С тоже ASSERT. Проблема в том, что ставить его должен программист. Но только оберон здесь опять никак не помогает. И в обероне его тоже должен ставить программист Придут на оберон индусы и "дух программирования по контракту с пред/пост условиями" тут же улетучится

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