Сразу оговорюсь - правильный ответ могут дать только архитекторы MS, которые задумывали эту логику. Нам лишь остается строить гипотезы. Тем не менее:
Цитата:
Сообщение от
Lankey
Не могли бы Вы пояснить немного:
1) Зачем существует demand, если уже и так запросили, что нужно, через assert ?
Это как-то зависит от того, где запросили (на сервере или клиенте?) или у assert есть scope? Я же не "напоминаю" коду о том. что объявила перееменные или там вызывала функции ранее
Я бы поняла, если бы была проверкка типа "If demand() = false" then asset() .... но так этот метод не используется.
Полагаю, что это связано с тем, что разные разработчики пишут код. Одни пишут требования (demand), другие реализуют выдачу разрешений (assert).
Аналогию можно провести с абстрактными методами. Один разработчик пишет метод и добавляет ему модификатор abstract, а другой (создавая наследник класса) вынужден перекрывать абстрактный метод, т.к. это требование первоначального разработчика
Цитата:
Сообщение от
Lankey
2) Почему мы запрашиваем разными классами (InteropPermission и fileIOPermission), что логично, а вот убираем одной CodeAccessPermission::revertAssert(), а не отдельно fileIOPermission::revertAssert и InteropPermission ::revertAssert .
Классы InteropPermission и fileIOPermission являются наследниками CodeAccessPermission. Полагаю, что выдача разрешений специфична и зависит от типа разрешения, а отзыв разрешения мог быть реализован единым методом вне зависимости от типа разрешения. Точно также, как метод finalize() может быть реализован на базовом классе, а метод new мы выполняем индивидуально на каждом наследнике.
Цитата:
Сообщение от
Lankey
3) revertAssert , как я понимаю, отменит все запросы, даже те, что были наложены в вызывающей функции , а не текущей?
4) revertAssert зачастую в конце кода, где выше по тексту запросили уже права, не делается. Это ошибка или есть в этом логика?
Отменится последнее выданное разрешение в текущем методе. Тут есть некоторый момент... Разрешение отзывается по завершению метода. Аналог - переменные типа Class. В конце области видимости переменной - она сама уничтожается и нет необходимости вызывать метод finalize().
Т.е. "для красоты кода" - нужно выдавать разрешения и их отзывать. Но... если разрешения не отозвать - то код "не сломается", хотя всякие Best Practice конечно скажут, что выданное разрешение надо обязательно отозвать.