Здравствуйте, Павел Кузнецов, Вы писали:

ПК>Т.е. отличия синтаксические, не семантические.

Ну, как видишь определение ссылочности зависит от типа, т.е. и то и другое.

Здравствуйте, Павел Кузнецов, Вы писали:

ПК>В результате они отличаются лишней косвенностью, и вряд ли адресная арифметика с ними имеет смысл.

Косвенности нет. И арифметика работает. Просто это Ансэйф, т.е. проблемы от их применения твои личные проблемы. В общем, переключение в век С++.

VladD2:

> ПК> В результате они отличаются лишней косвенностью, и вряд ли адресная арифметика с ними имеет смысл.

> Косвенности нет. И арифметика работает. Просто это Ансэйф, т.е. проблемы от их применения твои личные проблемы. В общем, переключение в век С++.

Ты уверен, что ты говоришь о managed pointers?

VladD2:

> ПК> Т.е. отличия синтаксические, не семантические.

> Ну, как видишь определение ссылочности зависит от типа, т.е. и то и другое.

Это решение одного из языков. Если в другом ссылки можно иметь на любые типы, ссылками от этого они быть не перестают.

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Продемострируй!
СГ>Слепи DLL и EXE. Пусть EXE динамически загрузит DLL и что-то с ней сделает такое, что она сможет сама вызывать хоть одну процедуру из EXE.

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

СГ>А что ты имеешь в виду под словом "функтор"?

стыдно не знать элементарных вещей

СГ>Речь, между прочим, идет об императивном языке.

в первый раз про это слышу

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Хорошо, скажем так: уменьшается размерность пространства всевозможных программ.
и такую глупость сколько не повторяй — умнее не станет. размерность пространства программ вообще от языка не зависит.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, rockandroll, Вы писали:

R>>Согласен. Принципиальных различий между ссылками и указателями (если не брать во внимание GC) я тоже не вижу. Может кто-нибудь видит?

VD>

VD>void f(ref A a);
VD>...
VD>A a = new A();
VD>f(ref a);
VD>

VD>

VD>void f(A ** a);
VD>...
VD>A * a = new A();
VD>a++;
VD>f(&a);
VD>

Если я не ошибаюсь, то оба варианта скомпилируются в практически одинаковы машинный код (если убрать a++ конечно из второго примера).
Т.е. я хочу сказать, что различия есть на уровне языка (Разный уровень абстракции, как сказал Дарней).

Здравствуйте, VladD2, Вы писали:

VD>Ага. Иначе такую чушь про процедурные переменные как единственный способ колбэк-вызовов не нес бы. Уж простят меня моредатры за резкость.

Процедурные переменные — это широкое понятие включающее в себя как просто указатели на обычные процедуры, указатели на методы (представляющие собой на самом деле 2 указателя: объекта и процедуры), интерфейсы как коллекции процедур содержащихся в одной переменной (в том числе и COM-овские интерфейсы как частный случай), и т.д. и т.п. Именно с помощью процедурных переменных реализуется полиморфизм на межмодульном уровне, в то время как внутри одного модуля можно было бы обойтись большим таким switch-ем, как правильно заметил мой оппонент.

Здравствуйте, VladD2, Вы писали:

VD>В общем, из пещеры пора вылезать.

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

Здравствуйте, Дарней, Вы писали:

Д>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Продемострируй!
СГ>>Слепи DLL и EXE. Пусть EXE динамически загрузит DLL и что-то с ней сделает такое, что она сможет сама вызывать хоть одну процедуру из EXE.

Д>предлагаю заняться этим самостоятельно, в качестве домашнего задания

То есть ты признаешь, что сделать это без процедурных переменных невозможно....

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>А указатель на функцию — это всего лишь одна из возможных реализаций процедурной переменной.

VD>О! Золотые слова! Вот и не нужно кормить детей самым низкоуровневым и примитивным их вариантам. Показывайте им интерфейсы и делегаты. Причем не в битах копайтесь, а показывайте как абстракцию. Тогда и притензий от дейатвующих программистов не будет.

А где Вы видели примитивные варианты? Уж не имеете ли Вы в виду тот казус, когда Вы под термином УКАЗАТЕЛЬ понимали АДРЕС и от этого приходили в бешенство?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Сергей Губанов, Вы писали:

VD>>>В Обероне ссылкой ничего не называют, так как нет их там.

СГ>>А давайте поспорим что есть?

VD>Спорь.

То есть Вы со мной согласны поспорить?
Я утверждаю что в оберонах ссылки есть, а Вы утверждаете что их там нет?

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Сколько раз повторять!!! Объектные переменные Java это не сами объекты (не value-type), а указатели на них (reference-type).

VD>Много раз повторять. Такую глупость сколько не повторяй, все равно она умней не стаент.

Уж не хотители Вы сказать, что в Java class это не reference-type, а value-type?

Здравствуйте, Сергей Губанов, Вы писали:
СГ>Процедурные переменные — это широкое понятие
Не, ну если в каждый из принятых терминов впихивать свое значение, то до чего угодно можно договориться.
З.Ы. А тебя самого на основе какого языка обучали программированию? И вообще, по какой программе.
Хотелось бы узнать, какими методами можно получить такую кашу в голове. Уж лучше не знать промышленных языков, чем иметь нарушенные представления о взаимосвязях явлений и сущностей. Типа там — что является абстракцией, а что реализацией, что является частью чего-то. Общее с частным тоже путать не стоит. Как и необходимое с достаточным.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Хорошо, скажем так: уменьшается размерность пространства всевозможных программ.
S>и такую глупость сколько не повторяй — умнее не станет. размерность пространства программ вообще от языка не зависит.

Представь себе императивный язык высокого уровня в котором нет переменных. Понятно что на нем нельзя написать ни одной программы, которая бы в процессе своей работы выполняла вычисления, связанные с манипуляцией памятью (например — текстовый редактор).

Здравствуйте, Курилка, Вы писали:

К>Отстутствие полей private является следствием того, что "единицей инкапсуляции является модуль"
К>Я хренею от обероновской логики, по мне дак женская ито намного понятней

Что Вы имеете в виду под отсутсвием private?

По умолчанию в оберонах ВСЕ ЕСТЬ PRIVATE. А раз все есть private, то зачем нужно само ключевое слово private?

Здравствуйте, Mamut, Вы писали:

M>И этому человеку (Вирту) не нравятся = и ==

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

Здравствуйте, Сергей Губанов, Вы писали:
СГ>Представь себе императивный язык высокого уровня в котором нет переменных. Понятно что на нем нельзя написать ни одной программы, которая бы в процессе своей работы выполняла вычисления, связанные с манипуляцией памятью (например — текстовый редактор).
Ну может уже хватит глупости-то писать? Например, в языке Форт нет никаких переменных, равно как и указателей. Тем не менее, он позволяет написать любую программу. Тебе уже не в первый раз намекаю — изучи азы. А то меня просто оторопь берет, когда я наблюдаю такое стремление обучать от столь человека с подобными тараканами в голове.

Здравствуйте, Mamut, Вы писали:

M>В догонку, совсем забыл.

M>Предположим, мой друг написал модуль Tools, выполняющий какие-либо действия. Он принес его мне и говорит, что на, дарю. У меня в проекте уже есть свой модуль Tools. Что мне делать?

M>В С++ и С# это решается с помощью namespace'ов. Довольно логичная система, легко обьясняется, легко используется.

M>Как это решается в Обероне?


Обратите внимание, что это не решается с помощью namespace'ов (так как имена всех namespace'ов тоже могут совпасть). Это решается только одним способом — надо договариваться об именовании или, по крайней мере, давать модулям длинные имена, чтобы свести к минимуму вероятность совпадения имен двух модулей от разных производителей. В Component Pascal длинные имена модулей не являются помехой, так как в секции импорта модулю можно назначить псевдоним.

MODULEКомпания1Подразделение1Проект1Система1Подсистема1Модуль1;

IMPORT StdLog, Services, Mmm := Компания2Подразделение2Проект2Система2Подсистема2Модуль2,
  Nnn := Компания3Подразделение3Проект3Система3Подсистема3Модуль3;

(*  Mmm и Nnn - это псевдонимы имен модулей *)
...

END Компания1Подразделение1Проект1Система1Подсистема1Модуль1.

Здравствуйте, Кодт, Вы писали:

К>Здравствуйте, Сергей Губанов, Вы писали:

СГ>>Повторяю. Единицей инкапсуляции является модуль. Все остальное следует из этого.

К>И это должны запомнить студенты/школьники?

Что конкретно Вас не устраивает?

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