OberonCore

PROCEDURE Dep*();
VAR a: ARRAY 10 OF CHAR;
p: PROCEDURE();
BEGIN
SYSTEM.GET(SYSTEM.ADR(a), p);
p();
END Dep;

Моему BB сносит крышу (печатает иероглифы).



Ну а к чему вы привязались к низкоуровневым возможностям C++, когда речь шла как раз о высокоуровневых?

А если с такой стороны посмотреть: какая доля драгоценного человеческого внимания при программировании на С++ затрачивается на чисто языковые аспекты (что обеспечить вот это "меньше 1%")? Я как-то уже приводил пример: если дать переобуть человека из постоянно давящих ногу ботинок в лёгкие тапочки, на которые он вообще не обращает внимание, насколько лучше ему будет думаться над задачей? И в итоге насколько меньше ошибок в логике будет им совершено? Трудно ведь делать два дела одинаково хорошо и сразу одной головой. Профессионал знает, что если плохо сделать дело аккуратного кодирования, то потом эти утёкшие указатели вовек не выловишь, даже с Numegaми всякими... В итоге он бессознательно отставляет логику на второй план, занимаясь ей преимущественно до (проектирование) и после (отладка) создания исходного текста. Сначала готовимся, потом долго-долго пробираемся по минному полю, и только потом начинаем пристреливаться по цели...

Оффтоп: вот это интенсивность обсуждения Три раза нажимал кнопку "Отправить", а мне выкидывало "Было добавлено ещё одно сообщение перед вашим"

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

Объясняю На пальцах. Вот я читаю:
DoSomething(x1, x2, x3);

Где у этой процедуры OUT-параметр?

Теперь сравните с:
x2 = DoSomething(x1, x3);

Какой код будет легче понять?

Однако доказать вы это так и не смогли...

Я так скажу - по существу никто толком ещё не сказал. Потому что влияние языка на качество продукта измерить нечем. Поскольку нет мерялки, то начинает работать бизнес-логика - "Мы вам сделаем, как вам удобнее. Тут прикрутим, там пришлёпаем. Оценить потери на борьбу с пришлёпками вы не сможете, поэтому заплатите без вопросов. Ещё и довольны останетесь".

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

P.S. Числу не нужно смеяться. Смеющееся число - это сюрреализм, это ненормально. Для выражения смеха есть другие способы, не столь вывернутые.

Метод, по идеологии ООП, это "навык", "умение" некоторого объекта. Его внутренняя активность.
i.ToString() предполагает, что число - оно объект, оно активное, оно знает про существование строк и оно умеет себя преобразовывать в строки. Нонсенс. Нормальная логика: должна быть какая-то то служба, которая умеет преобразовывать числа в строки. Или, может быть, основная служба, отвечающая за работу со строками, умеет их создавать сразу из элементарного численного значения. Далее смотрим документацию. Ненормальная массовая логика: пишем точку и ждём выпадающей меню. Ищем что-то, что отдалённо напоминает нам то, что нам надо. Находим - пробуем. Не находим - дико материм разработчиков "Ну как же они не научили числа делать ToString...". См. понятие "Танцующий медведь" у Купера "Психбольница в руках пациентов" (viewtopic.php?f=57&t=1052).

Тогда это не число, а объект, демонстрирующий число детям. "Актёр в роли числа".

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

Моё мнение: пока не прорвёмся от "смеющихся чисел" к понятиям уровня "стол" и "стул" в программировании, никакого принципиального сдвига в ИТ не будет. Так и будут все вместо инженерии с бубнами прыгать. Оберон - это большая и значимая веха на этом пути. Абсолютизировать его как "конец пути", конечно, никто не собирается.

Это - несущественная особенность Оберона... Таки язык проектировался как системный, аля Си. Таскать всё что угодно возвращаемым параметром - не лучшее решение. Да, можно и повыразительнее придумать, конечно.

А мой ББ культурно выдаёт trap(проверял 10 раз подряд):

Вот так. Среда корректно обработала ситуацию и не упала в агонии.


Скажу три вещи: 1) речь шла про DEP, я спросил именно про это "явление" 2) отвечать вопросом на вопрос невежливо. 3) вы первый начали


Не выдумывайте. Или вы такой формалист, что вам необходим "контрольный смайл" и очередное объяснение того что и так было сказано в 25-ти постах до того? Без обид.


К чему это? Но раз вы начали: Мирок - это абстракция со скрытой реализацией. Расширяем во все стороны. Безкомпромиссная опора на базовые типы не даёт ему превратиться в "колосс на глиняных ногах". Надеюсь, метафора ясна.


О, сорри, мозг мыслил только в контексте девелопинга. С этой точки зрения, конечно идея интересная. Некий сюр...


Не, не так. Вот так: SomeModule.DoSomething(x1, x2, x3); Мне без разницы какой код, я посмотрю интерфейс модуля SomeModule Вам вот эта возможность так дорога? Это ведь только выражение, не более...

Стоит ли овчинка выделки? И больше всего интересует оценочная цифирь, которой нет, нигде и ни у кого. Сказать, что "стоит" - легко, а без цифири - это пустой звук.

Блин. Вот есть у вас Object. И вы хотите залогать его. Какой из нижеприведенных способов "нонсенс", а какой наиболее удобный и естественный.
1) Вы делаете у базового Object метод ToString.
2) Вы делаете какую-то службу, которая знает обо всех типах объектов в системе и умеет их логать.
3) Вы делаете службу, в которой можно зарегестрировать преобразование в строку для любого типа.
4) Вы делает интерфейс IToString и пытаетесь кастнуть к нему Object.
5) Ваше предложение.

Понятно, что на все случаи жизни методов у Object'а не наделаешь (и не надо). Но ToString лично у меня не вызывает отторжения (а-ля смеющийся объект). Да, я соглашусь, можно и без этого утилитного метода. Но с ним удобнее.

Снег должен быть белым, а вода - жидкой. Число не должно смеяться. Если это число, конечно. С точки зрения того же индуса, зуб даю на отсечение, совершенно нормально писать кривой индусский код. Потому что реальность, данная ему в языке программирования - кривая. Мы-то с вами знаем, что это условности, что тут стакан стоял, а тут - рыбу заворачивали. Индус же не в курсе. Раз число может смеяться, то он будет шпарить всё, что в рамках этого прекрасного, широкого и удобного во всех отношениях мира.

Это я и сказал.

Я считаю это очень существенно для понимания и сопровождения незнакомого кода. Буквально пару недель назад фиксил вот такой привнесенный баг:



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

P.S. В реальном коде все конечно было намного более запущенно. Но суть та же.

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

От такого никак не защититься, кроме как воспитанием строгого мышления у программиста.