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

SE>Учтите только, что межконтекстные вызовы штука весьма тормознутая, и на межконтестные вызовы налагаются ограничения по JIT-оптимизации.

Насколько, приблизительно?

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

SE>>Учтите только, что межконтекстные вызовы штука весьма тормознутая, и на межконтестные вызовы налагаются ограничения по JIT-оптимизации.

T>Насколько, приблизительно?

Порядки.

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

L>Порядки.

Даже больше чем один? Сурово

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

L>>Порядки.

T>Даже больше чем один? Сурово

ты не представляешь сколько там всего делается.

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

T>Хотелось бы такого — чтобы можно было передать в чужой код ссылку на объект, и любая попытка его изменения приводила бы к исключению. Точнее, там не один объект, а сложная система из объектов с перекрестными ссылками. То есть нужно, чтобы блокировались вызовы методов, которые изменяют состояние.

Вначале, такие методы нужно как-то найти. Делать это в рантайме

T>Насколько я понимаю, в CLI вполне возможно добиться такого, с помощью перехвата вызовов например.

Готовой инфраструктуры для перехвата изменения состояния объекта в CLI нет. С другой стороны, если для работы с объектами используются интерфейсы то, можно написать framework который в "полу-автоматическом" режиме будет создавать read-only враппер для произвольного объекта.

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

_FR>"чужому коду" который занимается сортировкой требуется передать массив данных. Какой смысл запрещать этому коду изменять содержимое _FR>массива?
Потому что вот такой своеобразный подход к проектированию объектной модели.
Например, публичное свойство-последовательность, которое по логике вещей должно:
а) только читаться;
б) быть неизменяемой для клиентского кода последовательностью;
делается как:

public List<T> SomeSequence { get; set; }

вместо:

private List<T> _someListField;
public IEnumerable<T> SomeSequence
{ 
  get { return _someListField; }
}

Потом клиентский код делает SomeSequence.Clear() и все падает.

А List<T> оно потому что:
а) так удобней, потому что можно использовать auto-implemented property;
б) этот тип использовался в схожем примере в MSDN/блоге/и т.д.
в) так делает когодгенератор, кем-то написанный;
г) так с этим свойством легко работает какой-нибудь XmlSerializer;
д) так действительно получается меньше кода;
е) ... и еще миллион причин...

IMHO, такое имеет право на жизнь в ситуации, когда код объектов должен быть максимально-простым и тащить за собой минимум зависимостей.
Навскидку могу назвать один use-case, где подобное можно и нужно использовать — DTO. Но вот только граф DTO, полученный, например с клиента, подлежит последующей валидации.

В остальных случаях использовать такую модель не хочется...

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

TK>Вначале, такие методы нужно как-то найти. Делать это в рантайме

Пометить атрибутами или сделать маски имен. Это как раз несложно.

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

_FR>>"чужому коду" который занимается сортировкой требуется передать массив данных. Какой смысл запрещать этому коду изменять содержимое _FR>массива?
HL>Потому что вот такой своеобразный подход к проектированию объектной модели.
HL>Например, публичное свойство-последовательность, которое по логике вещей должно:
HL>а) только читаться;
HL>б) быть неизменяемой для клиентского кода последовательностью;
HL>делается как:
HL>

HL>public List<T> SomeSequence { get; set; }
HL>

HL>вместо:
HL>

HL>private List<T> _someListField;
HL>public IEnumerable<T> SomeSequence
HL>{ 
HL>  get { return _someListField; }
HL>}
HL>

HL>Потом клиентский код делает SomeSequence.Clear() и все падает.

Перечитайте пожалуйста сообщение, на которое дали ответ. Мои слова про массив имели отношение к тому, что было сказано топикстартером: "передать в чужой код ссылку на объект". Здесь же (List/Enumerable) обсуждается вопрос проектирования своего кода, что бы "чужой код" не мог бы cделать чего-то ненужного. Это несколько разные вопросы. Советы о том, как обеспечить неизменяемость своего кода нужны топикстартеру

HL>А List<T> оно потому что:
HL>а) так удобней, потому что можно использовать auto-implemented property;
HL>б) этот тип использовался в схожем примере в MSDN/блоге/и т.д.
HL>в) так делает когодгенератор, кем-то написанный;
HL>д) так действительно получается меньше кода;
HL>е) ... и еще миллион причин...

Достаточно одной — глупость и лень ей имя.

HL>г) так с этим свойством легко работает какой-нибудь XmlSerializer;

Сростить объект, который должден быть неизменяемым с XmlSerializer-ом задача сродни скрешивания ежа с ужом — и не получится ничего хорошего и процесс не понравится

HL>IMHO, такое имеет право на жизнь в ситуации, когда код объектов должен быть максимально-простым и тащить за собой минимум зависимостей.
HL>Навскидку могу назвать один use-case, где подобное можно и нужно использовать — DTO. Но вот только граф DTO, полученный, например с клиента, подлежит последующей валидации.
HL>В остальных случаях использовать такую модель не хочется...

Что имелось в виду под выделенным я не понял — свойства типа List или свойства типа IEnumerable?

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

T>Хотелось бы такого — чтобы можно было передать в чужой код ссылку на объект, и любая попытка его изменения приводила бы к исключению. Точнее, там не один объект, а сложная система из объектов с перекрестными ссылками. То есть нужно, чтобы блокировались вызовы методов, которые изменяют состояние.

Если объекты ваши, то можно замутить подобное с помощью того же PostSharp-а. Но это достаточно геморойно будет.

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

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

G>>Ну он же не сам получает — вы передаете

T>Ну да, можно перехватывать такие вызовы и отдавать прокси вместо ссылки. Но может быть, там уже есть такой функционал?

Ну тем же Unity делать прокси для объектов стороннего кода, которые проксируют передаваемые объекты

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

Всё никак успокоиться не можешь?

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

G>Ну тем же Unity делать прокси для объектов стороннего кода, которые проксируют передаваемые объекты

Это само собой! Просто пытаюсь сообразить, как это сделать с минимальным количеством гемора. Объектов то много и создаются в куче разных мест.

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

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

G>>Ну тем же Unity делать прокси для объектов стороннего кода, которые проксируют передаваемые объекты

T>Это само собой! Просто пытаюсь сообразить, как это сделать с минимальным количеством гемора. Объектов то много и создаются в куче разных мест.

Тупо позаменять new {Type}() на Container.Resolve<{Type}>(). Думаю это покроет довольно много сценариев.

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

_FR>Не представляю, так как не понимаю, что требуется Сначала давайте посмотрим на то, что нужно, а потом уже будем представлять, на сколько это сложно Так что же всё-таки требуется? может, пример можно привести?

Кажется, я понял. Он хочет что-то наподобие С++ const:

void GetItem(int& v) const; // здесь просто геттер такой, но он не меняет состояния своего инстанса.
void SetItem(const int& v); // а здесь сеттер, принимает ссылку, но объект по ссылке менять нельзя. Причём если это будет сложный объект, у него будут вызываемы только методы с модификатором const