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

3>Уже безотносительно возникающих в связи с этим проблем посторю вопрос:
3>Зачем запретили переопределение оператора присваивания?
Не запретили, а просто не делали.
Но во вторых у меня сразу возник вопрос:
1. Для кого приведение типов, для value или для reference типов? Операции присваивания для них разная.
2. В случае реализации для reference типов, сделаем клонирование, каким образом обеспечивать копирование ссылок?

Вообще, в C# для reference типов есть две различных операции. Присваивание ссылки, и клонирование. Обе операции разные по смыслу и синтаксису. Зачем их портить? Обеспечивать ту же сложность, где есть несколько операция для равно, как копирование ссылки, через конструктор присваивания, через перегруженный оператор — по моему большая гадость. Хрен узнаешь что же в результате получилось. Так что отсутсвие переопределения оператора присваивания, по моему правильно.

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

TK>Если очень хочется изменить поведение оператора присваивания то, это можно
TK>имитировать через неявное приведение типа.

Хочется немного дорого, хочется имея ссылки на один и тот же объект из разных коллекций ПРИСВОИТЬ этому объекту новое значение. Мне это желание кажется вполне естественным в слечае, если коллекции не мои (исходники отсутствуют) я не могу сделать это через items[i].MyAssignNewValMethod(newVal), ибо метод Add(bool overwriteExisting) реализует тот самый "overwriteExisting" как items[i] = newVal.

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

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

TK>>Если очень хочется изменить поведение оператора присваивания то, это можно
TK>>имитировать через неявное приведение типа.

3>Хочется немного дорого, хочется имея ссылки на один и тот же объект из разных коллекций ПРИСВОИТЬ этому объекту новое значение. Мне это желание кажется вполне естественным в слечае, если коллекции не мои (исходники отсутствуют) я не могу сделать это через items[i].MyAssignNewValMethod(newVal), ибо метод Add(bool overwriteExisting) реализует тот самый "overwriteExisting" как items[i] = newVal.
не понимаю как поможет тут переопределение оператора присваивания
если коллекции в закрытом виде (скомпилированы) там оператор присваивания скомпилирован именно как присваивание. ибо виртуалить операторы присваивания это нонсенс.

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

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

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

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

Mab>Относительно самого оператора -- за четыре года работы с .NET лично у меня такой необходимости не было Может у меня задачи не типичные, конечно.

У меня постоянно возникает желание воспользоваться этой фичей — для прозрачной поддержки
версионности объекта (типа DataRow.Accept/RejectChanges).
Если подскажешь как это сделать иначе, в достаточно общем виде — буду премного благодарен.

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

EC>У меня постоянно возникает желание воспользоваться этой фичей — для прозрачной поддержки
EC>версионности объекта (типа DataRow.Accept/RejectChanges).
EC>Если подскажешь как это сделать иначе, в достаточно общем виде — буду премного благодарен.
Свойства и индексеры никто не отменял:

public class Modifiable
{
  private bool _dirty;
  public bool IsDirty { get { return _dirty; } 
    protected void MarkDirty() { _dirty = true; }
}

public class Person
{
  private string _name;
  public string Name
    {
    set
        {
            if (_name == value) return; 
            _name = value;
            MarkDirty();
        }
        get { return _name; }
    }
}

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

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

S>

S>public class Modifiable
S>{
S>  private bool _dirty;
S>  public bool IsDirty { get { return _dirty; } 
S>    protected void MarkDirty() { _dirty = true; }
S>}

S>public class Person
S>{
S>  private string _name;
S>  public string Name
S>    {
S>    set
S>        {
S>            if (_name == value) return; 
S>            _name = value;
S>            MarkDirty();
S>        }
S>        get { return _name; }
S>    }
S>}
S>

Person наследует Modifiable?
Напрягает то, что надо во всех операциях модификации руками звать MarkDirty().

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

EC>Person наследует Modifiable?
Да, конечно.
EC>Напрягает то, что надо во всех операциях модификации руками звать MarkDirty().
А ты хотел перегрузить оператор присваивания для string? И каким это образом? Я все еще жду фрагмент гипотетического кода, который бы шибко выиграл от такой перегрузки.
По теме: такие вещи решаются при помощи АОП. Частности, вроде объектов с трекингом изменений, реализованы в ОЧЕНЬ большом количестве фреймворков. Насколько я знаю, в том числе и в BLToolkit.