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

AVK>Здравствуйте, Mr. None, Вы писали:

MN>>Есть класс, скажем, Composite, с ним связан класс, скажем, Node. У класса Composite есть метод OnSomeMessageFromNode — некий обработчик некоторого сообщения, которое может приходить только от объектов класса Node. Как гарантировать в компайл-тайме, что подообное сообщение ни от кого другого не придёт, с одной стороны и запретить объектам типа Node доступ к защищённым и собственным методам класса Composite?

AVK>Точного соответствия нет. Вариантов навскидку два:
AVK>

AVK>public class CompositeMessages
[skip]
AVK>

AVK>

AVK>public class CompositeMessages
[skip]
AVK>

вариант 1 не катит, любой класс находящийся в этой же сборке получит точно такой же доступ как и Node, более надёжный вариант предложеный Sinclair

Автор: Sinclair
Дата: 12.11.04

, но и у него есть недостатки, я описал их в ответе к тому посту.

нечто похожее на вариант 2 я и сам использовал как-то, но там тоже был какой-то минус относительно надёжности — можно было обойти все эти ухищрения, только сейчас не помню как... да и вообще, обращаясь к Node я не хочу писать CompositeMessages.Node... а если таких CompositeMessages будет несколько — для разных видов Composite?

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

AVK>Не понял вопроса

По определению, модуль — это единица исполнения. И если кто-то говорит. что класс выполняет роль модуля, то в каком смысле он выполняет эту роль? Как класс может исполняться?

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

СГ>Здравствуйте, AndrewVK, Вы писали:

AVK>>Не понял вопроса

СГ>По определению, модуль — это единица исполнения. И если кто-то говорит. что класс выполняет роль модуля, то в каком смысле он выполняет эту роль? Как класс может исполняться?

Т.е. любой модуль (единственно верный "обероновский", естественно) у нас есть EXE-шник, там чтоли?

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

AVK>>Не понял вопроса

СГ>По определению, модуль — это единица исполнения. И если кто-то говорит. что класс выполняет роль модуля, то в каком смысле он выполняет эту роль? Как класс может исполняться?

Все равно не понял. Обыкновенно может исполняться — вызываем метод и исполняемся на здоровье. В чем проблема то?

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

MN>вариант 1 не катит, любой класс находящийся в этой же сборке получит точно такой же доступ как и Node,

Это вобщем то не столь важно — сборку обычно ты можешь контролировать, все же исходный код у тебя есть в полном объеме.

MN> более надёжный вариант предложеный Sinclair

Автор: Sinclair
Дата: 12.11.04

,

Честно говоря никаких отличий между ними я не нашел.

MN>нечто похожее на вариант 2 я и сам использовал как-то, но там тоже был какой-то минус относительно надёжности — можно было обойти все эти ухищрения, только сейчас не помню как...

Через рефлекшен разве что. Других способов нет.

MN> да и вообще, обращаясь к Node я не хочу писать CompositeMessages.Node...

using Node = CompositeMessages.Node;

MN> а если таких CompositeMessages будет несколько — для разных видов Composite?

Тогда первый вариант самое оно.

Здравствуйте, Зверёк Харьковский, Вы писали:

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

ЗХ>>>Извините, конечно, но!

ЗХ>>>В этом форуме еще есть модераторы?

AVK>>Есть, но лучше без крайней необходимости их не призывать

ЗХ>то есть она, типа, еще не крайняя? уй...

Не поминай имя модератора всуе

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

MN>>вариант 1 не катит, любой класс находящийся в этой же сборке получит точно такой же доступ как и Node,

AVK>Это вобщем то не столь важно — сборку обычно ты можешь контролировать, все же исходный код у тебя есть в полном объеме.

Согласен, если полностью себе доверяешь ... Я обычно стараюсь ещё и от себя защититься — так сказать многоуровневая оборона, иногда помогает.

MN>> более надёжный вариант предложеный Sinclair

Автор: Sinclair
Дата: 12.11.04

,

AVK>Честно говоря никаких отличий между ними я не нашел.

У него Composite в одной сборке, Node и CompositeMessages — в другой.

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

AVK>>Честно говоря никаких отличий между ними я не нашел.

MN>У него Composite в одной сборке, Node и CompositeMessages — в другой.

Ну так я примерно то же предполагал.

Здравствуйте, AndrewVK, Вы писали:
AVK>Все равно не понял. Обыкновенно может исполняться — вызываем метод и исполняемся на здоровье. В чем проблема то?
Да Сергей все еще пытается опровергнуть неверное утверждение Silver_s о том, что класс в C# является более крутым аналогом оберонового модуля

Автор: Silver_s
Дата: 10.11.04

. Правда, он почему-то написал свое опровержение в ответ на твое опровержение того же утверждения.

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

MN>Ну этот вариант сработает. Но мне не нравится следующее:
MN>1) CompositeMessages и Composite фактически разделены, что не логично (хотя этот пункт весьма спорный);
MN>2) для каждой такой пары (Composite — Node) придётся делать 2 отдельный сборки, этак мы придёи к идее господина Губанова о 500 независимых модулей...
MN>3) но самое главное — небольшое усложенени исходной задачи сводит на нет эту реализацию...
Вообще говоря ты прав. Но надо отдать себе отчет в том, зачем вообще нужны спецификаторы доступа. Как я уже писал

Автор: Sinclair
Дата: 09.07.04

, эти спецификаторы являются некоторыми предикатами, налагаемыми на вызывающий код. В с++ предусмотрен метод раздачи исключительных прав путем friend, как дополнение к предоставленному предикату "является моим потомком".
В .Net вместо этого есть CAS, который позволяет раздавать привилегии с произвольной гранулярностью. Вносить это в язык нужным не посчитали. Трюки с компайл-тайм отловом нарушений контрактов нужны крайне редко. Примеры, которые ты приводишь, на первый взгляд напоминают "возьмите себя правой рукой за левое ухо... Как получилось?! Тогда не отпуская, поднимите левую ногу на уровень глаз и отхлебните кипяток из стакана". При проектировании возникают макрозадачи, непосредственно вытекающие из юс-кейзов, и микрозадачи — эдакие строительные кирпичи. При переходе от технологии к технологии макрозадачи остаются на месте, а вот кирпичи меняются. Удивляться этому не стоит, как не стоит и искать аналогов каждому кирпичу. Гораздо полезнее подняться на макроскопический уровень, и выполнить разложение на микрозадачи по-новому. Как правило, привычка решать задачи в рамках одной технологии диктует мгновенный и неосознанный выбор решения, которое может подойти, а может и не подойти к другой технологии. Особенно часты такие грабли в "визуально близких" технологиях — если тебе дать ту же задачу с ограничением "решить на SQL", то ты вряд ли начнешь страдать от отсутствия в нем protected и friend. А вот C# слишком синтаксически близок к С++, что провоцирует поиск в нем прямых аналогов привычным решениям.

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


К>Т.е. любой модуль <....> у нас есть EXE-шник, там чтоли?

Да, что-то в этом роде. Только в Windows есть небольшая разница между EXE, DLL, и прочими сортами бинарников, а в оберонистых модулях нет деления на несколько сортов, там все модули по форме одинаковы. Если все модули по форме идентичны, то загрузчик легче сделать, ведь он будет загружать всего 1 сорт модулей.

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

СГ>Да, что-то в этом роде. Только в Windows есть небольшая разница между EXE, DLL, и прочими сортами бинарников, а в оберонистых модулях нет деления на несколько сортов, там все модули по форме одинаковы. Если все модули по форме идентичны, то загрузчик легче сделать, ведь он будет загружать всего 1 сорт модулей.

Ну расскажи, чем же DLL так разительно отличается от EXE ?

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

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


К>>Т.е. любой модуль <....> у нас есть EXE-шник, там чтоли?

СГ>Да, что-то в этом роде. Только в Windows есть небольшая разница между EXE, DLL, и прочими сортами бинарников, а в оберонистых модулях нет деления на несколько сортов, там все модули по форме одинаковы. Если все модули по форме идентичны, то загрузчик легче сделать, ведь он будет загружать всего 1 сорт модулей.

А як оно запущаеца-то?
В каждом модуле есть ф-ция Main чтоли?
Всё-равно должна быть точка входа

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

S>Здравствуйте, Mr. None, Вы писали:

S>Трюки с компайл-тайм отловом нарушений контрактов нужны крайне редко. Примеры, которые ты приводишь, на первый взгляд напоминают "возьмите себя правой рукой за левое ухо... Как получилось?! Тогда не отпуская, поднимите левую ногу на уровень глаз и отхлебните кипяток из стакана". При проектировании возникают макрозадачи, непосредственно вытекающие из юс-кейзов, и микрозадачи — эдакие строительные кирпичи.

Согласен с тем, что это микрозадача. Но с тем, что это искусственный пример — не согласен.
Я не случайно в качестве примера привёл классы с именами Composite и Node. В моей практике при более-менее сложной реализации паттерна COMPOSITE нередко возникала задача внутреннего общения между элементами иерархии. Причём общение это должно было быть с одной стороны защищённое от внешнего доступа — не гоже, если кто-нибудь другой уведомит контейнер об изменении состояния его элемента, особенно когда состояние элемента не менялось. С другой стороны внутренняя реализация контейнеров и элементов должна быть защищена и скрыта друг от друга. Если эту иерархию реализует и использует один программист, то всё что я сказал излишне, но когда их больше одного могут начаться проблемы:
1) есть доступ к методу посылающему уведомление контейнеру, почему бы не послать от имени некоего элемента — не важно какого, не важно что нельзя, сейчас это решит мою проблему... правда потом всё может упасть, потому что обработку посылки сообщения контролирую не я, но ведь метод-то доступен;
2) есть возможность пронаследоваться от CompositeMessages и подпихнуть свой левый обработчик ноду, не важно что по спецификации нельзя — компилятор ведь позволяет и это решит мою проблему в данный момент времени...
3) ... и так далее
Поэтому ИМХО, всё что декларируется в спецификации как "нельзя" необходимо подтверждать таким же "нельзя" в коде. И желательно, чтобы отлов нарушения контрактов происходил в компайл-тайме, потому что и плюсы и шарп — это всё таки языки со статической типизацией, и надо её использовать по максимуму, потому как для динамической проверки контрактов в них не построена нужная инфраструктура. Если не нравится, пожалуйста есть прекрасные динамические языки, где предоставлены все удобства для динамической проверки условий контракта: Smalltalk, Self...

Вобщем вот, но это отступление от темы форума.

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

К>А як оно запущаеца-то?
К>В каждом модуле есть ф-ция Main чтоли?
К>Всё-равно должна быть точка входа

Ну, почти.

Можно написать так:

MODULE M1;

END M1.

А можно так:

MODULE M1;

BEGIN
 (* код, который будет выполнен при загрузке модуля в память *)
END M1.

Минимальная программа:

MODULE M1;
IMPORT StdLog;
BEGIN
 StdLog.String("Здравствуй Мир!");
END M1.

Здравствуйте, Sergey J. A., Вы писали:

SJA>Ну расскажи, чем же DLL так разительно отличается от EXE ?

Не расскажу. Военная тайна.

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

[skipped]

Т.е. получаем одну и ту же фигню, что и в случае длл и экзе — разница минимальна, так что же ты хотел этим сказать?

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

СГ>Здравствуйте, Sergey J. A., Вы писали:

SJA>>Ну расскажи, чем же DLL так разительно отличается от EXE ?

СГ>Не расскажу. Военная тайна.

Ага, тайна святых воителей во имя небесночистого Оберона

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

СГ>Да, что-то в этом роде. Только в Windows есть небольшая разница между EXE, DLL, и прочими сортами бинарников,
Это миф. В Windows используется ровно один тип загружаемых модулей — так назывемый PE-формат. "Прочие сорта бинарников", навроде com и старых exe, оставленных для обратной совместимости, можно не рассматривать, т.к. они вообще выполняются в рамках legacy 16-разрядной подсистемы.

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

СГ>Минимальная программа:
СГ>

СГ>MODULE M1;
СГ>IMPORT StdLog;
СГ>BEGIN
СГ> StdLog.String("Здравствуй Мир!");
СГ>END M1.
СГ>

А как её запустить в Чёрном Коробке ? Если выделить M1 и выбрать в меню Execute ничего не выполняется?