Assignment operator for __value types

[Edward Diener]

Is there a way to override the default processing of the assignment operator
for one's own __value types ? I realize I can program my own Assign method,
and provide that for end-users of my class, but I would like to use
internally my own = operator for some of my value types, so I can say "x =
y;" rather than "x.Assign(y);".

The op_Assign operator seems impossibly broken since it takes __value copies
of the two objects. Perhaps there is some other way.

 

[Eric Gunnerson [MS]]

There is no way to overload the assign operator.

You may be able to get what you want by overloading a conversion operator to
convert from y to x; that would allow you to write "x = y";

--
Eric Gunnerson

Visit the C# product team at http://www.csharp.net
Eric's blog is at http://weblogs.asp.net/ericgu/

This posting is provided "AS IS" with no warranties, and confers no rights.

 

[Edward Diener]

There is no way to overload the assign operator.

That is unfortunately what I thought.

You may be able to get what you want by overloading a conversion
operator to convert from y to x; that would allow you to write "x =
y";

No I want to overload the default behavior when one says:

X x;
X y;
// Do something with x to change it.
y = x;

where X is one of my own __value classes.

I think it is a weakness of the CLR that one can't override this behavior to
supply one's own functionality instead of the default behavior for
user-defined __value types. I admit I am not sure what the default behavior
is, whether it is a byte-by-byte copy of data from x to y, or whether it is
a field-by-field copy of data from x to y, or whether it takes into account
property values and gets and sets the appropriate properties when moving the
data. I know that when X is a __value class with properties, I want the get_
and set_ method for each property to be called if I say y = x, but I suspect
that is not the case. That is the reason I was hoping to override the
default assignment somehow.

My workaround is to provide a 'void X::Assign(X)' in order to do the
assignment, so that instead of writing y = x, I would write instead
y.Assign(x), but this is much less natural than the normal assignment
operator and y = x.

Needless to say, in C++ one can overload the default assignment operator
with 'X & operator = ( X /* or const X & */);'. Maybe CLR should revisit
this inability and make changes in the future which allows overriding the
assignment operator for user-devined __value classes possible.

 

[Daniel O'Connell]

That is unfortunately what I thought.


No I want to overload the default behavior when one says:

X x;
X y;
// Do something with x to change it.
y = x;

where X is one of my own __value classes.

I think it is a weakness of the CLR that one can't override this behavior to
supply one's own functionality instead of the default behavior for
user-defined __value types. I admit I am not sure what the default behavior
is, whether it is a byte-by-byte copy of data from x to y, or whether it is
a field-by-field copy of data from x to y, or whether it takes into account
property values and gets and sets the appropriate properties when moving the
data. I know that when X is a __value class with properties, I want the get_
and set_ method for each property to be called if I say y = x, but I suspect
that is not the case. That is the reason I was hoping to override the
default assignment somehow.

My workaround is to provide a 'void X::Assign(X)' in order to do the
assignment, so that instead of writing y = x, I would write instead
y.Assign(x), but this is much less natural than the normal assignment
operator and y = x.

Needless to say, in C++ one can overload the default assignment operator
with 'X & operator = ( X /* or const X & */);'. Maybe CLR should revisit
this inability and make changes in the future which allows overriding the
assignment operator for user-devined __value classes possible.

Interesting...this is one of those features(operator overloading in general,
outside of mathematics of course) I think should be left to die a slow
death.

 

[Jon Skeet [C# MVP]]

No I want to overload the default behavior when one says:

X x;
X y;
// Do something with x to change it.
y = x;

where X is one of my own __value classes.

I think it is a weakness of the CLR that one can't override this behavior to
supply one's own functionality instead of the default behavior for
user-defined __value types.

I have to say that I couldn't disagree more. One thing I *like* is
knowing what will happen on assignment (when only one type is involved,
and thus no implicit conversions) *without* having to look up the
details of the type.

If you want a way of creating a copy of a value, write a Copy method or
something similar (which I think is clearer than calling Assign on an
existing value) - but leave the rest of us with a system where we don't
need to wonder what every single line of code means, however simple!

 

[Edward Diener]

Interesting...this is one of those features(operator overloading in
general, outside of mathematics of course) I think should be left to
die a slow death.

It is alive and well, fortunately, but I am not going to get into a polemic
about it. I know only too well the arguments on both sides ( C++ has had it
from its inception ) and I know how much I approve of it myself and that is
all I will say.

Clearly .NET supports it although it is not CLS compliant. I just wanted to
use it in my own code for clarity, while providing a CLS Assign member
function also for other .NET languages.

Rather than get into an argument about overriding the built-in = operator
for value types, I will present a situation where it may not do what I want
it to do. I have a value type, let us call it X as in the above example,
which has a property, and also an event which is triggered when the property
changes. So in my property set function, I trigger the event. If I assign
one X to another using the built-in = operator, does my property set
function get called or does the built-in = operator just copy the underlying
X data from one to the other ? If the latter, then my event never gets
triggered, and event handlers which need to know when the property changes
never get called when using = to assign one object of the value type to
another.

In the Assign member function of value type X, I assign the property from
one to another which assures that the event gets triggered. If I could
override the built-in assignment operator = , I would do the same. Obviously
I can use Assign instead, but I have to remember to use it rather than the
more natural = assignment.

 

[Edward Diener]

I have to say that I couldn't disagree more. One thing I *like* is
knowing what will happen on assignment (when only one type is
involved, and thus no implicit conversions) *without* having to look
up the details of the type.

If you want a way of creating a copy of a value, write a Copy method
or something similar (which I think is clearer than calling Assign on
an existing value) - but leave the rest of us with a system where we
don't need to wonder what every single line of code means, however
simple!

Do you feel the same thing about overriding other operators also, or is your
uncomfortableness just about overriding the assignment operator ? I am just
curious because it is fruitless to get into an argument about operator
overriding. Obviously most C++ programmers like me love it, since it has
been part of the language since its inception and we are very much aware of
its advantages and disadvantages, while many others who have never used it
dislike it, largely for the reason you have given.

 

[Jon Skeet [C# MVP]]

Do you feel the same thing about overriding other operators also, or is your
uncomfortableness just about overriding the assignment operator ? I am just
curious because it is fruitless to get into an argument about operator
overriding. Obviously most C++ programmers like me love it, since it has
been part of the language since its inception and we are very much aware of
its advantages and disadvantages, while many others who have never used it
dislike it, largely for the reason you have given.

I feel wary about introducing any operator overloads. They should be:

a) Entirely natural
b) The kind of thing which is bound to be commonly used
c) Very explicitly documented

For instance, it's handy having == and + overridden for string, and
having DateTime's relationship with TimeSpan (e.g. DateTime-
DateTime=TimeSpan, DateTime+TimeSpan=DateTime etc). For a few standard
types, it's fine - because everyone knows about it. When it comes to
3rd party classes which other developers will be less familiar with, I
get much more dubious.

I'm pretty uncomfortable with explicit conversion operators, and very
uncomfortable with implicit conversion operators. It basically means
code is being called where it doesn't look like any is. (Properties are
relatively obvious by convention - otherwise I'd be doubtful about
them, too.)

I can see the advantages when you know what's going on - but I'm a
*very* big fan of making the code as readable as possible to someone
who may come to maintain my code without necessarily being as
intimately familiar with the rest of the codebase as I am.

 

[Daniel O'Connell]

Eric Gunnerson [MS] wrote:
There is no way to overload the assign operator.

That is unfortunately what I thought.


You may be able to get what you want by overloading a conversion
operator to convert from y to x; that would allow you to write "x =
y";

No I want to overload the default behavior when one says:

X x;
X y;
// Do something with x to change it.
y = x;

where X is one of my own __value classes.

I think it is a weakness of the CLR that one can't override this
behavior to supply one's own functionality instead of the default
behavior for user-defined __value types. I admit I am not sure what
the default behavior is, whether it is a byte-by-byte copy of data
from x to y, or whether it is a field-by-field copy of data from x
to y, or whether it takes into account property values and gets and
sets the appropriate properties when moving the data. I know that
when X is a __value class with properties, I want the get_ and set_
method for each property to be called if I say y = x, but I suspect
that is not the case. That is the reason I was hoping to override
the default assignment somehow.

My workaround is to provide a 'void X::Assign(X)' in order to do the
assignment, so that instead of writing y = x, I would write instead
y.Assign(x), but this is much less natural than the normal assignment
operator and y = x.

Needless to say, in C++ one can overload the default assignment
operator with 'X & operator = ( X /* or const X & */);'. Maybe CLR
should revisit this inability and make changes in the future which
allows overriding the assignment operator for user-devined __value
classes possible.

Interesting...this is one of those features(operator overloading in
general, outside of mathematics of course) I think should be left to
die a slow death.

It is alive and well, fortunately, but I am not going to get into a polemic
about it. I know only too well the arguments on both sides ( C++ has had it
from its inception ) and I know how much I approve of it myself and that is
all I will say.

Clearly .NET supports it although it is not CLS compliant. I just wanted to
use it in my own code for clarity, while providing a CLS Assign member
function also for other .NET languages.

Rather than get into an argument about overriding the built-in = operator
for value types, I will present a situation where it may not do what I want
it to do. I have a value type, let us call it X as in the above example,
which has a property, and also an event which is triggered when the property
changes. So in my property set function, I trigger the event. If I assign
one X to another using the built-in = operator, does my property set
function get called or does the built-in = operator just copy the underlying
X data from one to the other ? If the latter, then my event never gets
triggered, and event handlers which need to know when the property changes
never get called when using = to assign one object of the value type to
another.

In the Assign member function of value type X, I assign the property from
one to another which assures that the event gets triggered. If I could
override the built-in assignment operator = , I would do the same. Obviously
I can use Assign instead, but I have to remember to use it rather than the
more natural = assignment.

The question here, in my mind anyway, is should that event be raised anyway?
Is x = y still x? or is it y with no handler? Thats part of what I am
worried about, an assignment that instead of performing proper value
semantic copying is used to copy only pieces of the value, breaking value
semantics. In my opinion when I set x to y, then any event handler
references recorded in x should be destroyed along with the other data in x,
and y should be put in its place. No event should be raised because the
property *didn't* change, the variable that originally contained the
property did, but that is an entirely different beast.

 

[Daniel O'Connell]

Do you feel the same thing about overriding other operators also, or is your
uncomfortableness just about overriding the assignment operator ? I am just
curious because it is fruitless to get into an argument about operator
overriding. Obviously most C++ programmers like me love it, since it has
been part of the language since its inception and we are very much aware of
its advantages and disadvantages, while many others who have never used it
dislike it, largely for the reason you have given.

Since I meant to clarify a bit in the other thread but forgot to before I
posted, I'll post this bit here.

I personally have nothing against responsible use of operator overloading,
like Jon I like being able to overload == when appropriate, and having
string +string and other such short cuts is handy, however some constructs
are fincky and unpleasent(and considering the .NET implementation of
operator overloading, some things are a little t0o fussy anyway). The
feature is powerful, but dangerous, and I frown more upon unfettered and
irresponsible use of the feature than the feature itself. I see far too
often, even in C#, where an operator overload is done simply because the
original programer would rather type + or because he doesn't want to
explicitly cast, that kind of behaviour is troubling.
And, while those experianced in C++ will be discriminating(although not
always to my tastes), its not the masters I worry about, they, unfortunate
as it may be, are the minority. It is the mediocre and the amateur
programmer that will usually cause real damage with operator overloading.

Now, that said, I do have a particular problem with overloading the
assignment operator, as I addressed in part in my other posts. I simply
don't like to be guessing what I'm actually doing in the simplist line of
code possible in the language I'm working in. I don't think I'd like to find
a ref type that is always actually a value assignement, nor do I want to
find value assignments that aren't really value assignments, but partial
copies into the existing valuetype. Its just to complicated and it is far
too easy to get caught in a surprise because of it.

 

[Edward Diener]

Eric Gunnerson [MS] wrote:
There is no way to overload the assign operator.

That is unfortunately what I thought.


You may be able to get what you want by overloading a conversion
operator to convert from y to x; that would allow you to write "x
= y";

No I want to overload the default behavior when one says:

X x;
X y;
// Do something with x to change it.
y = x;

where X is one of my own __value classes.

I think it is a weakness of the CLR that one can't override this
behavior to supply one's own functionality instead of the default
behavior for user-defined __value types. I admit I am not sure what
the default behavior is, whether it is a byte-by-byte copy of data
from x to y, or whether it is a field-by-field copy of data from x
to y, or whether it takes into account property values and gets and
sets the appropriate properties when moving the data. I know that
when X is a __value class with properties, I want the get_ and set_
method for each property to be called if I say y = x, but I suspect
that is not the case. That is the reason I was hoping to override
the default assignment somehow.

My workaround is to provide a 'void X::Assign(X)' in order to do
the assignment, so that instead of writing y = x, I would write
instead y.Assign(x), but this is much less natural than the normal
assignment operator and y = x.

Needless to say, in C++ one can overload the default assignment
operator with 'X & operator = ( X /* or const X & */);'. Maybe CLR
should revisit this inability and make changes in the future which
allows overriding the assignment operator for user-devined __value
classes possible.

Interesting...this is one of those features(operator overloading in
general, outside of mathematics of course) I think should be left to
die a slow death.

It is alive and well, fortunately, but I am not going to get into a
polemic about it. I know only too well the arguments on both sides (
C++ has had it from its inception ) and I know how much I approve of
it myself and that is all I will say.

Clearly .NET supports it although it is not CLS compliant. I just
wanted to use it in my own code for clarity, while providing a CLS
Assign member function also for other .NET languages.

Rather than get into an argument about overriding the built-in =
operator for value types, I will present a situation where it may
not do what I want it to do. I have a value type, let us call it X
as in the above example, which has a property, and also an event
which is triggered when the property changes. So in my property set
function, I trigger the event. If I assign one X to another using
the built-in = operator, does my property set function get called or
does the built-in = operator just copy the underlying X data from
one to the other ? If the latter, then my event never gets
triggered, and event handlers which need to know when the property
changes never get called when using = to assign one object of the
value type to another.

In the Assign member function of value type X, I assign the property
from one to another which assures that the event gets triggered. If
I could override the built-in assignment operator = , I would do the
same. Obviously I can use Assign instead, but I have to remember to
use it rather than the more natural = assignment.

The question here, in my mind anyway, is should that event be raised
anyway? Is x = y still x? or is it y with no handler?

My own notion of assignment is that the data changes but not the event
handlers. I may be wrong about how I view it however. All the more reason to
allow me to override the assignment operator ( = ) for my own __value
classes. Remember that I am largely doing this internally for my own ease of
use, while providing a CLS Assign member function which I will document for
any potential end-user.

Thats part of
what I am worried about, an assignment that instead of performing
proper value semantic copying is used to copy only pieces of the
value, breaking value semantics. In my opinion when I set x to y,
then any event handler references recorded in x should be destroyed
along with the other data in x, and y should be put in its place.

Fair enough. That certainly is a way of seeing things, and you may be right
as the address of event handlers is certainly part of an object. Still I
tend to only assign non-event data values in my own object assignments,
while making sure that nothing in the state of the object is out-of-sync
after the assignment,

No
event should be raised because the property *didn't* change, the
variable that originally contained the property did, but that is an
entirely different beast.

If the underlying property value changes, I want to trigger the event. I
think this is far more normal than not doing so in the case of assignment,
as the change in the underlying property will be important to an event
handler.

 

[Edward Diener]

I feel wary about introducing any operator overloads. They should be:

a) Entirely natural
b) The kind of thing which is bound to be commonly used
c) Very explicitly documented

Your a) and b) are very personal interpretations, but c) I will agree with
100%. Perhaps because I, unlike many programmers, thoroughly document my
classes and components for end-users that I am much more comfortable with
operator overloading. Of course with CLS, operating overloading is not
compliant so my main use for it is to present myself with an easier notation
to use that I know rather than the longer, and often less elegant IMO, use
of member functions.

For instance, it's handy having == and + overridden for string, and
having DateTime's relationship with TimeSpan (e.g. DateTime-
DateTime=TimeSpan, DateTime+TimeSpan=DateTime etc). For a few standard
types, it's fine - because everyone knows about it. When it comes to
3rd party classes which other developers will be less familiar with, I
get much more dubious.

I'm pretty uncomfortable with explicit conversion operators, and very
uncomfortable with implicit conversion operators. It basically means
code is being called where it doesn't look like any is. (Properties
are relatively obvious by convention - otherwise I'd be doubtful about
them, too.)

I can see the advantages when you know what's going on - but I'm a
*very* big fan of making the code as readable as possible to someone
who may come to maintain my code without necessarily being as
intimately familiar with the rest of the codebase as I am.

Of course, but that is what good documentation is all about.

 

[Jon Skeet [C# MVP]]

Of course, but that is what good documentation is all about.

Yes, but if I need to read documentation carefully to find out whether
even the simplest line of code is going to do what I expect it to or
not, I think that's a problem. I'm glad operator overloading hasn't
been used too extensively in the rest of the framework - and I wouldn't
rely on it being used. (For instance, I'll use .Equals rather than ==
almost everywhere, the exceptions being value types and string, pretty
much. I rarely need a reference identity comparison particularly, but
then if I were in an appropriately diligent mood I'd probably
explicitly use object.ReferenceEquals.)

I don't want to have to look up the assignment operator on every single
type I use (repeatedly - there's no way I could remember the behaviour
of all of them) just to do simple variable assignment with no
conversions involved.

 

[Edward Diener]

Yes, but if I need to read documentation carefully to find out whether
even the simplest line of code is going to do what I expect it to or
not, I think that's a problem. I'm glad operator overloading hasn't
been used too extensively in the rest of the framework - and I
wouldn't rely on it being used. (For instance, I'll use .Equals
rather than == almost everywhere, the exceptions being value types
and string, pretty much. I rarely need a reference identity
comparison particularly, but then if I were in an appropriately
diligent mood I'd probably explicitly use object.ReferenceEquals.)

I don't want to have to look up the assignment operator on every
single type I use (repeatedly - there's no way I could remember the
behaviour of all of them) just to do simple variable assignment with
no conversions involved.

I don't think anyone is going to change the assignment operator to be
totally non-conformant to what others expect. My own Assign actually assigns
each of the properties, thus forcing events associated with those changing
properties. I could be wrong but I don't believe that the default assignment
operator does that, and therefore the event handlers for those changes
wouldn't be called. I think my own Assign works better than the default
assignment as I understand it, and would be documented in such a way if I
could override the default assignment operator also. I don't believe this is
a big issue for programmers using my class to understand. But actually I
wanted to do it for my own use and not for the outside world since operators
are not CLS compliant anyway.

The issue to me with any overridden operator is still documentation. Whether
I am dealing with native types, or user-defined types, I want to know what
operations on those types mean. Absorbing the fact that a user-defined type
does something slightly different is not to me a particularly big problem.
It would if the operator did something totally unexpected. I can see from
where you are coming but C++ programmers have gotten used to operators being
overridden and changing the meaning of common operations, but they have also
gotten used to the idea that when one does that, one also is generally
responsible for both documenting the difference and making that difference
very similar to the general functionality expected of the operator.

 

[Jon Skeet [C# MVP]]

The issue to me with any overridden operator is still documentation. Whether
I am dealing with native types, or user-defined types, I want to know what
operations on those types mean. Absorbing the fact that a user-defined type
does something slightly different is not to me a particularly big problem.
It would if the operator did something totally unexpected. I can see from
where you are coming but C++ programmers have gotten used to operators being
overridden and changing the meaning of common operations, but they have also
gotten used to the idea that when one does that, one also is generally
responsible for both documenting the difference and making that difference
very similar to the general functionality expected of the operator.

Just because C++ programmers have become used to it doesn't mean that
it's a good thing, or that everyone else should have to get used to it.
Yes, the assignment operator should do useful things, but because it
*can* do something different from what the programmer happens to expect
(and whenever there are two or more reasonable choices, one of them is
bound to be contrary to what some people expect) you need to look in
the documentation for what the assignment operator does for every type.
Currently, I don't have to do that. I don't want to have to do that.

 

[Edward Diener]

Just because C++ programmers have become used to it doesn't mean that
it's a good thing, or that everyone else should have to get used to
it. Yes, the assignment operator should do useful things, but because
it *can* do something different from what the programmer happens to
expect (and whenever there are two or more reasonable choices, one of
them is bound to be contrary to what some people expect) you need to
look in the documentation for what the assignment operator does for
every type. Currently, I don't have to do that. I don't want to have
to do that.

"Just because .NET programmers have not become used to it doesn't mean that
it's a bad thing, or that no one else should not have to get used to
it. Yes, the assignment operator should do useful things, but because
it *can* do some useful and different thing from what the programmer happens
to
expect (and whenever there are two or more reasonable choices, one of
them is bound to be better than what some people expect) you need to
look in the documentation for what the assignment operator does for
certain types. Currently, I have to do that for certain types. I do want to
have
to do that in order to get more useful functionality."

I could not resist because our disagreement can never be resolved. I will
only say that it is much more of a programming philosophical issue than
anything else. I will readily admit that the programming idioms with which I
am comfortable generally sacrifice safety and consistency for semantic and
idiomatic flexibility, whereas .NET, and perhaps your own programming
philosophy, emphasizes safety and consistency much more.

Still my request for the ability to override the assignment operator was not
theoretical but had an ease of programming point about it for me.
Nonetheless if .NET doesn't allow a useful override for the assignment
operator, certainly mention of op_Assign should be removed from the
documentation.

BTW, and I know this is bad NG etiquette, I have documented what I believe
is a serious .NET bug in another poston this NG recently. I know I can call
MS to try to get a viable workaround ( I still have two free incidents ),
but if you can confirm it or at least tell me I am wrong about it, it would
be helpful to me.

 

[Jon Skeet [C# MVP]]

I could not resist because our disagreement can never be resolved.

That's fair enough Good discussion though.

BTW, and I know this is bad NG etiquette, I have documented what I believe
is a serious .NET bug in another poston this NG recently. I know I can call
MS to try to get a viable workaround ( I still have two free incidents ),
but if you can confirm it or at least tell me I am wrong about it, it would
be helpful to me.

No problem - what's the thread called?