OberonCore

Кстати, а что вас так смутило? Вот вы расскажите какому-нибудь смоллтолкеру, что у вас базовые типы - это не объекты, а фиг знает что, и что им нельзя послать сообщение - он тоже будет очень удивлен такому "нерегулярному" дизайну языка...

Страшнее

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

Ну мы же не про смоллток говорим, где всё - объект. И не про лисп, где всё - список. А про язык, на котором получается предсказуемый, самодокументируемый код без выкрутасов.

Это ж какие там запрятанные нюансы? Что у базового типа можно вызвать ToString()? В чем загадка-то? Не вижу я в обероновском варианте никаких четко выделенных сущностей. Наоборот - вижу загадочное объявление никому не нужного массива символов, который зачем-то передается в функцию. О том, что в этом массиве в какой-то момент окажется преобразованное в строку число, можно догадаться только из контекста.

Код без выкрутасов - исключительно на совести писателя, об чем и речь. А про степень самодокументированности я уже неоднократно говорил - у оберона она вообще ниже плинтуса (на уровне С без плюсов).

Загадка - зачем целочисленному типу иметь метод преобразования в строку? Ну объясните, почему целое число (число - сущность некоторой природы) надо рассматривать как объект (структура совершенно другой природы)? Почему число (число - которое от 0 до MAX(INT)) должно иметь метод (ну это бред сивой кобылы) преобразования этого числа в строку? В психиатрии, думаю, такому мышлению точно найдётся подходящий диагноз.



Загадочное? Догадаться? Бог с Вами, Влад Там явное преобразование одной сущности в другую В отличие от.

Зачем есть в природе Strings.IntToString?



За теорией - к смоллтолкерам. По мне так это просто удобно.



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



Да, по сравнению с i.ToString - весьма загадочное. Явное преобразовании сущности одну в другую - это "y = f(x)". Все остальные формы (в виде объявлений переменных, массивов, передачи по ссылке и т.п.) - это отклонения в угоду несовершенному миру в лице ЯП. В обероне за этими отклонениями не видно сути (y = f(x)).

Наверное, имелось в виду следующее: unit - это гомогенная сущность в памяти. Вся занимаемая ей память предназначена только для хранения только определённых однородных данных только в определённом порядке.

Объект - это гетерогенная сущность. В нём могут храниться не только числа, и они не обязаны всегда располагаться, скажем, перед строками. Соответственно, количество способов обработки данных не ограничено. Значит, нужны "ручные" способы их обработки (обычно располагаемые внутри самих же объектов), поскольку в процессор их уже не поместить. Или ещё раз: обект - это гетерогенная сущность с "беспорядочным" расположением данных и алгоритмами их обработки. В языке присутствует механизмы создания объектов и запуска алгоритмов обработки.

Внутри unit нет алготимов обработки, но методы запуска алгоритмов обработки языка всё-таки что-то вызывают, что, насколько я понял, и раздражает.

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

Не, я все равно не понимаю... Вот в C++ объект можно очень точно положить в нужную ячейку памяти (и гарантировать, например, что для процессора он будет ничем не отличаться от int'а) и выполнить над ним сколь угодно высокоуровневые операции. Откуда берется противопоставление объект vs железо?

Наверное благодаря именно таким "фокусам" появилась возможность "выполнения данных", которую все кинулись предотвращать (см. DEP).

Влад, Вы прямо в точку! Я сам ощущаю, что у меня очень узкое и инертное мышление. Когда мне показывают стол, и говорят, что это "стол", я понимаю, о чём речь. Когда мне показывают корову, и называют её коровой - я соглашаюсь! Когда мне показывают число, и говорят, что оно может смеяться (i.GetSmiling()), то я смутно ощущаю, что меня пытаются обмануть. Число смеяться не может! Это же число! Число - понятие, которое зародилось в древней Индии, даже раньше. Число не может само себя преобразовать в строчку, не может вычислить косинус самого себя, потому что число - внимание - статично! Это абсолютно пассивная сущность. Из-за недостаточной гибкости восприятия и отсутствии на этой почве фантазии, мне трудно понять, почему число может производить какие-то действия. Я привык, что действия производят над числом.



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

Нет, для "выполнения данных" достаточно старого доброго C с его буферами на стэке. Или SYSTEM.

Ммм. Покажете?
А что это, вы, собственно, привязались к SYSTEM? Резонно сравнивать последствия использования одного глубоко системного модуля(о котором и известно-то благодаря доке и открытым исходникам) и последствия тех вольностей, которые позволяет C++ в обычном порядке?
*это я сел недавно изучать C++ по книжке "С++ для чайников", так на разделе "работа с указателями" не один раз ловил в демках системные ошибки
**"я привёл "плюсы" как пример только потому, что даже в fpc я с таким не сталкивался, если честно...

Все относительно. Если предствить, что вы программируете мир, в котором практически все может смеяться (по разному, но может), то в рамках этого мира i.GetSmiling() вполне естественно даже для числа. В рамках фрэймворка .NET практически все имеет строковый эквивалент - это очень удобно, например для логгинга. Поэтому i.ToString() в рамках этого фрэймворка вполне естественно.



Да какая разница? Это ж только форма записи. Ну было бы не i.ToString(), а ToString(i). Что это принципиально меняет для чтения кода (отставим пока в стороне инкапсуляцию)? А вот то, что в обероне у функции появляется второй параметр (который на самом деле ее результат) - серьезно затрудняет чтение.



Я имею ввиду математическое описание функции.



Ой, только не надо начинать про "=" vs ":=". Мне наплевать в каком языке каким значком обозначается операция присваивания.

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


Ну, это получается процедура с OUT-параметром, разве нет? НЕ функция.

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

Я не прочь провести бесчеловечный оберон-эксперимент над живым индусом, если б такие водились поблизости

И делается это с помощью "new". unit не нужно инициализировать. И язык тут ни причём.Я имел в виду не то, что объекты не очень точно распологаются в памяти друг относительно друга, а то, что Вы можете скомпилировать такой код (представлен схематично) или такой кодвместе с классами, которые его используют. Причём, классы не придётся менять, и всё будет работать. То есть, структура класса не обязана соответствовать каким-то аппаратным требованиям. И вообще, переменные в классе могут объявляться хоть после процедур. Это ничего не изменит для класса, потому что это абстракция, и к её данным обращается не процессор, а другая абстракция средствами языка. А транслятор потом...

На нижнем уровне всё, конечно, эмулируется через базовый тип (или типы) процессора, где и про методы уже речи нет.

Кстати, в отличие от объектов, внутри unit нельзя делать перестановок и надеятся на всё тот же результат: методы обработки занесены в процессор и "перекомпилировать" их вместе с новой структурой unit ничего нельзя.неплохо бы иметь такой процессор : ). Среди всего прочего, уменьшили бы головную боль людям, пишущим кодогенераторы компиляторам. А программисты, наконец-то, могли бы забыть про процессор.Я их не противопоставляю, а различаю. Только из-за того, что объект в общем случае - сущность произвольная, а железо поставляет весьма ограниченный набор фиксированных структур.

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

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

Да не программированию. Просто арифметике, или другой игре, в которой могут появиться числа. Или просто в качестве спецэффекта на одной из заставок.