OberonCore

О, а поподробнее? Я внчале тоже думал, что там целые числа. например, объектами не являются, но вот описание ключевого слова int в C#:

C# Programmer's Reference
int (C# Reference)

The int keyword denotes an integral type that stores values according to the size and range shown in the following table.


Смотрим, что такое System.Int32:

.NET Framework Class Library
Int32 Structure

Represents a 32-bit signed integer.

The Int32 value type represents signed integers with values ranging from negative 2,147,483,648 through positive 2,147,483,647.

Int32 provides methods to compare instances of this type, convert the value of an instance to its String representation, and convert the String representation of a number to an instance of this type.

Так же и символы, и булевы значения -- все они вполне себе объекты, правда, напрямую от класса Object не происходящие, но наследующие разные интерфейсы...

Вот об этом и я, и Vlad, вам и говорим...

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

Сервер не должен знать обо всех потенциально возможных клиентах.
Клиент должен знать о сервере, интерфейсом которого пользуется.
Никакой третий переводчик не может знать всё обо всех... Например, ОС предоставляет окружение и транспорт для серверов и потенциальных клиентов, но ничего не знает об их интерфейсах. На самом деле ОС является сервером как для серверов, так и для клиентов.

Почитайте обсуждение с начала. Речь шла о попустительстве багам со стороны ЯП. Версия о противостоянии "IBM vs индусы-обфускаторы" лично меня не интересовала никогда и вряд ли заинтересует вообще.

Не могу найти. Это книга или в интернете статьи где-то лежат?

Ну, у меня есть. Он обещал Тарасову на Арбинаде выложить после переработки, но пока ждём...

Я не уверен, что теория пространств(или групп, или как правильно) имеет прямое отношение к моей абстракции. Я такой смысл не вкладывал. Вы видимо в этом разбираетесь, решайте сами.
Я описал алгоритм преобразования. Я не знаю, что во что превращается. Я только знаю, раз нужно превращение, то никакие другие методы преобразования не подходят. Причём тут тождественность? Объекты абсолютно произвольной природы, не известно наперёд, что они такое, кролик или голубь.
Ну я не могу не ввести преобразователь(он должен знать с чем работает, иначе как можно управлять тем, чего не знаешь), ведь предполагается что элементы а и б ничего не знают друг о друге. И нет у меня ни серверов, ни клиентов... 3 сущности. В абстракции - никак не связанные своей природой. Где вы тут увидели аспекты реализации? А сервер и клиент - это значит нормально, можно смириться? Цилиндр как пример преобразователя, абстрактный, по сути, чёрный ящик. На входе кролик, на выходе голубь. А про то что онвместилище, это уже аспект реализации(и очень конкретно, я думал, мы об абстракциях, а вы непонятно о чём).Вы пыльцу превращаете в цветок? Или наоборот? Не вижу связи со строками и числами даже отдалённой.Извините, я должен признать что не понимаю ваших мыслей и аналогий. Вы мои понимаете, и опровергаете. А я в этом вашем посте смысла не увидел. Перефразируйте пожалуйста, если не трудно.

Трудно
Я Вас просил привести пример из природы, где был бы промежуточный слой, занющий всё обо всех действующих лицах.

Не нужно знать "обо всех" действующих лицах. Я и не говорил о таком. Надо знать только о том, "что" и во "что" преобразовывается. Базовые сущности и компонентность сделают остальную работу. Например, возьмём CO2 на входе и O2 на выходе как сущности разной природы(да газы, но суть базовые сущности) + хлоропласты в растительных клетках(чем не фокусник?). Скомпонуйте хлоропласты и получите лист. На этом уровне абстракций пример полностью удовлетворяет "моей" модели.

Да, не нужно преобразователю знать ВСЁ о пространствах А и В.
Но совсем не обязательно включать их в себя. Касательно перевода числа в строку - достаточно прибавлять к value числа, входящего на преобразование, число 48(0х30 или 30h) и на выходе будет ASCII код символа.
Потому прямое указание на включение в пространство преобразователя пространств А и В лишнее в Вашем описании. Именно оно является аспектом реализации и сужает выразительные возможности изначальной абстракции из трёх сущностей(А,В,преобразователь).
Для кроликов с голубями добавления "30h" явно маловато, но откуда возьмётся функция подстановки - с сервера или будет она методом класса/типа, или взята из реализации интерфейса - в данном случае уже неважно. Достаточно объявить механизм её поиска/получения/доступа. Не надо "сапоги с цветами смешивать".

p.s. однородные - это когда в А - только кролики, в В - только голуби

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

Реализация должна быть узкой. Моя абстракция:(А,В,преобразователь из А в Б). Я не изобретаю один преобразователь для всего, я описываю компонент преобразования А в Б. Постарайтесь перечитать мои посты и понять, о чём я говорю. Иначе смысла о чём то спорить просто нет.Во, появились сущности: метод, класс, сервер. А всё потому, что вы что-то упустили. Что есть прибавка как не использование возможностей голубя, суть импорт, суть включение в себя? Что есть использование значения кролика как не то же самое включение? И никуда вы не денетесь от этого. Потому что изначально а и б - абстракции. Преобразователь только познав их суть, может изменять их содержимое. Взгляните на глубоко промышленное выращивание пшеницы. Опишите строгий базис, и постройте на нём устойчивую систему. Разумный подход к организации.

Да, конечно... Только завтра появляется новое расширение базиса - и опять думай, что делать... Поучится то же, что имеем сейчас - надстройку над надстройкой, заплатку над заплаткой...

Как говорил один мой преподаватель "Вы неверно выбрали базис". Что ж это за базис, если уже завтра он должен быть изменён?

Вы ошиблись. Спор с Вами целесообразно было бы производить в личке, но мне более интересно поучаствовать в обсуждении темы, нежели бросить пару-тройку философских цитат и столько же получить в ответ.

Однако и я ошибся. Видимо в том, что присоединившись к обсуждению набора из трёх сущностей я НЕ предположил, что "преобразователь" может использоваться как-то ещё, кроме как "преобразователь из А в Б". Спасибо, что указали мне на это.

Что касается использования значений, без познания их сути, то попробуйте перечитать пример из моего предыдущего поста. Уверен, что таким образом легко можно преобразовать идентификатор кролика в ASCII-строку для голубиной почты. И при этом не понадобится включать в преобразователь суть кроликов и почтовых голубей королевства. Возможно, Вы что-то упустили.

Ко всему прочему я ещё сторонник существования и использования "базовых" сущностей. Я предполагаю, что такая сущность, если она базовая, составляет основу системы и не нуждается в интерфейсах, или, в сервере(ведь это тоже придётся назвать базовыми сущностями). Смысл базовой сущности определяется её ТИПом, тем пространством(однородным) в котором она существует. Тип - полный, простой, и самодостаточный. Под этим я понимаю то, что собственно ТИП уже определяет правила работы с сущностью. Если базис(набор базовых типов/сущностей) определён правильно, то все остальные необходимые элементы системы(расширенные) смогут быть скомпонованы из этих типов, соответственно, и преобразованы они будут посредством преобразователей базовых типов. На этом уровне НЕ нужно вводить преобразователей для расширенных типов. Всё что сверх этой схемы - или расширение типа, или аспект реализации. Пример, как мне кажется: языки Оберон-семейства.
Теперь по поводу преобразования "число-строка" и вашего примера. По-моему, в духе всеобщего абстрагирования, возня с ASCII как пример очень неудачна. Вы представляете символ как код, как цифру, и работаете с ним соответственно. Конечно, на уровне реализации, я думаю, такой подход оправдан, эффективен и верен(относительно). Просто вы "недоабстрагировали" всё до нужного уровня. По-вашему получается, что нужно базовый тип подогнать под преобразователь, или же ввести ещё один слой, для такого приведения.Ну, я считаю что весь этот базар кому-то может быть полезен. Поэтому лучше публично обсуждать, при этом соблюдая формальности.

Защититься как раз можно. Для этого достаточно возвращать стрктуру как результат функции (и именно так и был переписан код). Но не в обероне.

Так это же нарушение условия частичной инициализации, если я правильно понял задачу.

Дык, в массиве может быть любая фигня, вот и имеем undefined behavior как в старом добром C/C++



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



Ну вот, опять метафоры... А без метафор и аналогий никак? Чтобы было очевидно как 2 * 2?



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

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

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