OberonCore

(я второго абстрактного решения не видел, кроме "компоновки" - но это ведь не того уровня абстракция)! Итак, Ваш ход.

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

Я не понимаю, чего Вы (здешнее Оберон-сообщество) хотите тогда на самом деле?

Можно ещё смотреть с другой стороны: код - это текст, а программирование - создание текста.

Напряжённость, имхо, это состояние, связанное с повышенными энергозатратами. Может, разные степени энергозатрат и удобнее называть по-разному - стресс, подъём, или как-то ещё.

Приученный к ситуации "число может над собой делать что угодно", полезет в документацию, искать методы этого числа. А приученный к "число отдельно, обработка отдельно", полезет искать способы обработки этого числа. При наличии должной документированности, оба способа абсолютно идентичны.

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

структурированная знаковая система любого типа, выделенная из какого-либо (природного — событие, явление, отношение, или созданного — "вторая реальность", в т.ч. произведение искусства) денотатного поля с целью извлечения информации. Сам термин — "текст" в семиотическом случае никакого сугубо лингвистического содержания не имеет и является только образным названием знаковой системы.
...
Само вложение информации в ТЕКСТ адресантом (если таковой присутствует, а не имеется в виду какое-либо природное явление, напр. предгрозовые признаки как ТЕКСТ предсказания грозы) как и получение информации из ТЕКСТА адресатом прямо связано с КОДИРОВАНИЕМ информации и ДЕКОДИРОВАНИЕМ данного ТЕКСТА. В одном денотатном поле может быть зафиксировано множество структурированных ТЕКСТОВ. Так, напр., конкретный человек может быть одновременно рассмотрен как медицинский, социальный, правовой, криминальный, эстетический и т.д. ТЕКСТ. ...

Ведь передёргиваете! Как любил говорить небезызвестный YK, "подмена тезиса!". Вместо абстракции информационного содержания задачи Вы всё тыкаете в конкретную кривую реализацию "мэйнстрима". Да кто бы спорил, что она кривая! Вот если б хотя бы относительно прямую (Смоллток) попробовали, тогда ещё было бы интересно. Но мы ж не об этом, а о сути задачи!

То, что от этой схемы надо уходить, понятно всем. Но Вы путаете парадигму (ну пусть методологию) с конкретной реализацией, а это не есть гут!

Вот Вы и подтвердили мои слова о Вашем понимании...
Поймите же, что суть задачи - выполнить операцию В над сущностью А в контексте Б. Всё! Ваши i и object есть частные случаи, возможные представления сущности А, и между ними НЕТ РАЗНИЦЫ в контексте задачи!

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

При этом Вы, с одной стороны, теряете исполнителя (я ж приводил пример с вещественной арифметикой), а с другой стороны, ставите сами себе непреодолимые пределы в части высокоуровневых абстракций.

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

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

Ничего я не передёргиваю. В Смолтолке всё объект, потому что там действительно всё объект. В C# не всё является объектом, потому что там действительно не всё является объектом. К Смолтолку претензий и не предъявлялось: хотят сделать i.toString() - пожалуйста, ведь у них - всё объект, и взаимодействие с объектами однороны. Но в большинстве мэйнстримовых языков - не всё объект. Там как минимум два класса сущностей (в угоду себе, любимым). Но почему-то впилить toString() им захотелось туда, где взаимодействие отличается от взаимодействия объекта кардинально. В ООП нигде нет запрещений на создание таких объектов. Никто в кривом ООП не запрещает всё сделать объектом. Однако, метод toString() появился там, где он недоступен даже в кривом ООП. Ну и кто здесь непоследователен?Это вы путаете конкретную реализацию с парадигмой. Я не говорил, что это неправильно, я говорил, что там неправильно, и что так делать нельзя. Когнитивность? Там ею только пахнет.

ЗЫ Я очень даже за возможность работы с числами-объектами.
Я пытаюсь сводить всё многообразие многомерности задачи не к единственному уровню, а к одному уровню, что методически верно: упрощается работа на текущем уровне, потому что предыдущий уровень один и однороден. То же самое делаете и Вы. Но только Вы, почему-то, считаете верным записать i.toString() при любых обстоятельствах, в то время как я согласен с этим только на определённых условиях. Поскольку i не равно object, и существуют разные контексты, то можно найти и такие контексты, когда различия существенны. При сложении, возможно, разницы действительно нет, но при попытке занести значение в формуляр, распечатать его, затем отсканировать и распознать исходное значение сущности могут возникнуть проблемы (у объекта могли быть атрибуты, которые на формуляр не печатались). Почему я к этому так прилип? Потому что на процессорах Intel даже перестановка двух идущих подряд строк инициализации переменных может существенно сказаться на производительности. В object.toString() будет выполняться object.toString(), а в i.toString() не будет выполняться i.toString(). Это замыливает взгляд, требуется помнить этот нюанс. И если даже порядок инициализации сказывается на производительности, то что может сделать такое поведение? О какой прозрачности может идти речь? Ну и у кого здесь лишние сущности : )?

P.S. Как Вы так быстро ответы даёте? Я один раз нажал "отправить", а там Ваше новое сообщение. Прочитал, жму "отправить", а там ещё одно Ваше сообщение : ).

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

промежуточного слоя

Тогда в ходу все возражения в части комбинаторики

но ведь так удобнее!

Однако, это уже серьёзное ограничение! С чего это текст?

Опять же, см. выше - исключаем из языка все легальные возможности, не оставляя программисту ничего. Путь ФП

Где-то в её недрах есть один маленький байт. Если Вы хотите, чтобы этот байт был объектом в смысле ООП и умел делать toString(), то добавьте к этому байту, скажем, ещё 70 байт (кода). После этого, объект сможет себя напечатать. Но этого недостаточно: если мы имеем дело с объектом, то неплохо бы использовать инкапсляцию, скрыв прямое обращение к данным. Чтение и запись значения - это ещё по 7 - 10 байт. Операция сравнения - ещё примерно 10 байт.

Уверен, если ваши работодатели дадут вам задание сделать максимально обфусцированный код, в котором никто кроме вас не разберётся, то вы без проблем придумаете как это сделать в вашем суперстрогом обероне...

Текст как знаковая система

"число отдельно, обработка отдельно"

Позвольте, а это что?

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

Будете ли Вы спорить с тем, что этот вариант от его систематизации только выиграет?

А вот варианты такой систематизации могут быть разными. Из известных мне я лично считаю лучшим классы типов.

смесь постановки задачи

элементы соответствующих множеств

Причем правило "f" - не оговорено, отсутствуют даже правила формирования этого "f"

пространство преобразователя ... должно включать в себя пространства А и Б

Не множеств, а пространств элементов произвольной природы.

А это уже аспект реализации. Определяйте как вам только угодно.

Возможно вы поняли всё слишком прямо.

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

Удобнее так думать? Или просто удобнее код строчить и частные задачи решать?