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

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

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

3>Уже безотносительно возникающих в связи с этим проблем посторю вопрос:
3>Зачем запретили переопределение оператора присваивания?

Да не запрещали его!
И не могли запретить. Потому что в C# его никогда и не было!

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

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

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

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

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

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

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

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

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

ie>>А что приведение типов уже отменили?
V>очень удобно и безопасно!!!
Да в фв1.1 такие очень удобные и безопасные вещи на каждом шагу и закрывать глаза на все остальное и жаловаться на IClonable это уже слишком.

Уже безотносительно возникающих в связи с этим проблем посторю вопрос:
Зачем запретили переопределение оператора присваивания?

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

3>Уже безотносительно возникающих в связи с этим проблем посторю вопрос:
3>Зачем запретили переопределение оператора присваивания?

Блин, меня самого это немного бесит, ведь можна прикольно мутиться его перегружая.

По крайней мере можна обойтись определением неявного преобразования типов: public static implicit operator

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

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

Аналогичная ситуация, всегда хватало стандартного присваивания + IClonable.

Hello, "3axapov"
> Уже безотносительно возникающих в связи с этим проблем посторю вопрос:
> Зачем запретили переопределение оператора присваивания?

Я так понимаю, что очень хочется иметь возможность писать на C# что-то
подобное коду на C++?

class A
{
public:
 // т.к. все классы в .net создаются в хипе то, фактически это указатели.
 A* operator= (A* original)
 {
  return nullptr;
 }
};

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

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

Это все понятно. Но от избытка сахара диабет бывает Лично мне приятно, что когда я пишу a = b для ссылочных типов, это означает ровно то, что написано -- присваивание ссылок, а некий посторонний вызов, который, что-то там сделает в стороне и незаметно.

Опять же, допускаю, что есть задачи, сплошняком состоящие из таких присваиваний с побочным эффектом. Но почему-то мне они кажутся довольно редкими. Что делать, если встретится: менять инструмент, смириться и писать вызовы методов или, наконец, пересмотреть дизайн, подогнав его под способности языка.

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

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

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

ie>Аналогичная ситуация, всегда хватало стандартного присваивания + IClonable.

Ха, и чем же хватает IClonable, если он возвращает долбаный object — ну во втором наверное уже есть генерик интерфейс.

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

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

3>Уже безотносительно возникающих в связи с этим проблем посторю вопрос:
3>Зачем запретили переопределение оператора присваивания?

Если перегрузить оператор присваивания, возникнет конфликт с пропертями.
Не понятно, что нужно вызывать — сеттер или перегруженный оператор.
ИМХО, наличие пропертей значительно полезнее перегрузки оператора присваивания (весь фреймворк на пропертях работает).

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

ie>>Аналогичная ситуация, всегда хватало стандартного присваивания + IClonable.

D_A>Ха, и чем же хватает IClonable, если он возвращает долбаный object — ну во втором наверное уже есть генерик интерфейс.

А что приведение типов уже отменили?

D_A>Думаю, для ответа на даный вопрос нужно перечислить ситуации — когда оправдано применение даного опреатора. Если таких нет, или они реализуются стандартными способами, не теряя при этом легкости и удобства — тогда он точно не нужен

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

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

MF>Если перегрузить оператор присваивания, возникнет конфликт с пропертями.
MF>Не понятно, что нужно вызывать — сеттер или перегруженный оператор.
Ну пускай всегда бы выполнялся сеттер. А внутри сеттера уже можно оператор дергать. Пока что не вижу проблемы

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

ie>А что приведение типов уже отменили?
очень удобно и безопасно!!!

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

V>очень удобно и безопасно!!!
Что мешает написать дженерик-версию данного интерфейса?

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

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

V>>очень удобно и безопасно!!!
Mab>Что мешает написать дженерик-версию данного интерфейса?
недоступность второго фреймворка

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

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

ie>>>А что приведение типов уже отменили?
V>>очень удобно и безопасно!!!
ie>Да в фв1.1 такие очень удобные и безопасные вещи на каждом шагу и закрывать глаза на все остальное и жаловаться на IClonable это уже слишком.

Скажу так — наличие операции приведения типов в коде — значит чтото неправильно спроектировано, не так ли?
Еще 1 пример неправильного проектирования — наличие ветвлений в коде — я не говорю про реализацию там математического вычисления, а ветвление по типу например — использование оператора Ис. Все должно разруливаться с помощью:
— полиморфизма;
— паттерн Стэйт;
— паттерн Визитор (двойная диспетчеризация),...

(небольшое отступление)

Сама идея даного интерфейса — нормально подходит для метода клонирования например коллекции данных элементов, но...
Коллекция непонятно что содержит — нетипизированная ведь, непонятно что призойдет вообще. Короче, приведите мне хоть 1 пример оправданого использования даного оператора без приведения типов в итоге...

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

Но все же думаю красивое применение должно найтись сдесь: здесь в разделе Алгоритмы -> Идиомы и стили С++

Просто давно не перечитывал, а так — всем рекомендую почитать

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

D_A>Скажу так — наличие операции приведения типов в коде — значит чтото неправильно спроектировано, не так ли?
Очень категоричное утверждение. Нет, в общем случае не так.

D_A>Еще 1 пример неправильного проектирования — наличие ветвлений в коде — я не говорю про реализацию там математического вычисления, а ветвление по типу например — использование оператора Ис. Все должно разруливаться с помощью:
D_A>- полиморфизма;
D_A>- паттерн Стэйт;
D_A>- паттерн Визитор (двойная диспетчеризация),...
Опять же, кто кому чего должно? is-matching для сред типа .NET или Java вполне устоявшаяся парадигма. В том же Nemerle он вполне удобно поддерживается среди других способов matching-а. Ну а уж что именно применять, зависит от кокретной задачи.

D_A>Но все же думаю красивое применение должно найтись сдесь: здесь в разделе Алгоритмы -> Идиомы и стили С++
У C++ свои порядки и концепции. Скажем, довольно пренебрежительное отношение к RTTI весьма типично для C++-программистов. В .NET Reflection и близкие к нему динамические идеи намного более популярнее.

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

ie>>>>А что приведение типов уже отменили?
V>>>очень удобно и безопасно!!!
ie>>Да в фв1.1 такие очень удобные и безопасные вещи на каждом шагу и закрывать глаза на все остальное и жаловаться на IClonable это уже слишком.

D_A>Скажу так — наличие операции приведения типов в коде — значит чтото неправильно спроектировано, не так ли?

Да, так, но далеко не всегда. В этом случае не так. Когда мы начинаем использовать .NET мы должны соглашаться с правилами которые тот предлагает. Правильно он спроектирован или нет — тут уж никуда не денешься.

D_A>Еще 1 пример неправильного проектирования — наличие ветвлений в коде — я не говорю про реализацию там математического вычисления, а ветвление по типу например — использование оператора Ис. Все должно разруливаться с помощью:
D_A>- полиморфизма;
D_A>- паттерн Стэйт;
D_A>- паттерн Визитор (двойная диспетчеризация),...

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

D_A>(небольшое отступление)

D_A>Сама идея даного интерфейса — нормально подходит для метода клонирования например коллекции данных элементов, но...

Если речь не идет о deep copy, то никакого "но" и не возникает.

D_A>Коллекция непонятно что содержит — нетипизированная ведь, непонятно что призойдет вообще. Короче, приведите мне хоть 1 пример оправданого использования даного оператора без приведения типов в итоге...

Сердце мое полно жалости — я не могу этого сделать. Я вообще не вижу использования IClonable без приведения типа после — оно подразумевается по умолчанию.

D_A>А насчет переопределения оператора присваивания — да, трудно вспомнить надобность его наличия — неявного приведения типов хватает для создания контейнеров прототипов, которые легко можно использовать в контексте некой операции, к параметрам которой неявно могут приводиться эти прототипы — все юнит тесты так работают

D_A>Но все же думаю красивое применение должно найтись сдесь: здесь в разделе Алгоритмы -> Идиомы и стили С++

Когда же наконец-то придет в этот мир понимание о том, что сравнивать ++ и # ну просто нельзя. Разные подходы в программировании на этих языках. И использовать один подход в другом языке, ну просто нельзя.

D_A>Просто давно не перечитывал, а так — всем рекомендую почитать

Спасибо, почитаем, но оставим эти знания до той поры, когда придется писать на плюсах.

Да я не говорю о плохой архитектуре фрэймворка — именно в своем коде прикольно тогда, если нет операций приведения типов — многие этим пренебрегают, мол если можна, то сделаем. А вообще концепция такова, что таких ситуаций впринципе не должно возникать. Тоесть приведение объекта к типу потомка — а почему так получилось — сдесь получается, что логика, работая с базовым классом знает о потомках — а если добавится еще что-то...
Просто некорректность. Вот с энамами постоянно появляется приведение типов, если восстанавливать его из инта или наоборот. Ну... дождались 2ого фрвк — там можна извращаться с дженериками, а что еще лучше — вложенными в дженерики классами, и всем остальным.

А насчет ++ и # — я не пишу уже давно на ++, и не сравниваю эти языки. Все правильно, в ++ можна легко напороть на рантайм ошибку, но вот кастинги в # — тоже могут приводить к Каст или НулРэференс эксепшнам — тоесть напартачить можна, если злоупотреблять этим оператором. Да, не спорю, всему вина — отсутствие в 1ом фрвк дженериков — может сбоить ФОРИЧ, вдруг чтото не то положили — вся проблема в этом. Тоетсь это практически единственная ситуация, когда возникает кастинг, в иных случаях не должно быть этого. компарэйбл интерфейс — это тоже решится со 2ым фрвк.

Тоетсь, если мы пишем на 2ом фрвк — где нужен кастинг от базового к подтипу?...

А насчет статьи — там довольно прикольные извраты описаны, и их знание ничем не противоречит концепциям шарпа, тк не использует чегото специфического ++. Ну почти все Многое уже реализовано в шарпе схожими вещами, но вообще — статья просто супер!!!

Здравствуйте, 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.