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. 16 2543
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" <ed******@tropicsoft.com> wrote in message
news:Ot**************@TK2MSFTNGP12.phx.gbl... 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] 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.
This posting is provided "AS IS" with no warranties, and confers no rights. "Edward Diener" <ed******@tropicsoft.com> wrote in message news:Ot**************@TK2MSFTNGP12.phx.gbl... 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.
"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:ei**************@tk2msftngp13.phx.gbl... 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.
This posting is provided "AS IS" with no warranties, and confers no rights. "Edward Diener" <ed******@tropicsoft.com> wrote in message news:Ot**************@TK2MSFTNGP12.phx.gbl... 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.
Edward Diener <ed******@tropicsoft.com> wrote: 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 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!
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Daniel O'Connell wrote: "Edward Diener" <ed******@tropicsoft.com> wrote in message news:ei**************@tk2msftngp13.phx.gbl... 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.
This posting is provided "AS IS" with no warranties, and confers no rights. "Edward Diener" <ed******@tropicsoft.com> wrote in message news:Ot**************@TK2MSFTNGP12.phx.gbl... 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.
Jon Skeet [C# MVP] wrote: Edward Diener <ed******@tropicsoft.com> wrote: 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 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.
Edward Diener <ed******@tropicsoft.com> wrote: 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.
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:ey*************@TK2MSFTNGP11.phx.gbl... Daniel O'Connell wrote: "Edward Diener" <ed******@tropicsoft.com> wrote in message news:ei**************@tk2msftngp13.phx.gbl... 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.
"Edward Diener" <ed******@tropicsoft.com> wrote in message
news:eV*************@TK2MSFTNGP11.phx.gbl... Jon Skeet [C# MVP] wrote: Edward Diener <ed******@tropicsoft.com> wrote: 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 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.
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.
Daniel O'Connell wrote: "Edward Diener" <ed******@tropicsoft.com> wrote in message news:ey*************@TK2MSFTNGP11.phx.gbl... Daniel O'Connell wrote: "Edward Diener" <ed******@tropicsoft.com> wrote in message news:ei**************@tk2msftngp13.phx.gbl... 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.
Jon Skeet [C# MVP] wrote: Edward Diener <ed******@tropicsoft.com> wrote: 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.
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.
Edward Diener <ed******@tropicsoft.com> wrote: 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.
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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] wrote: Edward Diener <ed******@tropicsoft.com> wrote: 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.
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.
Edward Diener <ed******@tropicsoft.com> wrote: 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.
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Jon Skeet [C# MVP] wrote: Edward Diener <ed******@tropicsoft.com> wrote: 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.
"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.
Edward Diener <ed******@tropicsoft.com> wrote:
<snip> 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?
--
Jon Skeet - <sk***@pobox.com> http://www.pobox.com/~skeet
If replying to the group, please do not mail me too This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Edward Diener |
last post by:
I have a __value class which uses some legacy C++ code. So I wrapped the
legacy C++ code in another __nogc class and have a pointer to that class as
a member of my __value class. When the __value...
|
by: Edward Diener |
last post by:
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,...
|
by: Marcus Kwok |
last post by:
I have been reading through the ManagedExtensionsSpec.doc file and I
thought something was not clear.
If I have a __value class (really a __value struct but that shouldn't
make a difference) and...
|
by: MeoLessi9 |
last post by:
I have VirtualBox installed on Windows 11 and now I would like to install Kali on a virtual machine. However, on the official website, I see two options: "Installer images" and "Virtual machines"....
|
by: Aftab Ahmad |
last post by:
Hello Experts!
I have written a code in MS Access for a cmd called "WhatsApp Message" to open WhatsApp using that very code but the problem is that it gives a popup message everytime I clicked on...
|
by: Aftab Ahmad |
last post by:
So, I have written a code for a cmd called "Send WhatsApp Message" to open and send WhatsApp messaage. The code is given below.
Dim IE As Object
Set IE =...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: marcoviolo |
last post by:
Dear all,
I would like to implement on my worksheet an vlookup dynamic , that consider a change of pivot excel via win32com, from an external excel (without open it) and save the new file into a...
|
by: isladogs |
last post by:
The next Access Europe meeting will be on Wednesday 6 Mar 2024 starting at 18:00 UK time (6PM UTC) and finishing at about 19:15 (7.15PM).
In this month's session, we are pleased to welcome back...
|
by: Vimpel783 |
last post by:
Hello!
Guys, I found this code on the Internet, but I need to modify it a little. It works well, the problem is this: Data is sent from only one cell, in this case B5, but it is necessary that data...
|
by: jfyes |
last post by:
As a hardware engineer, after seeing that CEIWEI recently released a new tool for Modbus RTU Over TCP/UDP filtering and monitoring, I actively went to its official website to take a look. It turned...
|
by: ArrayDB |
last post by:
The error message I've encountered is; ERROR:root:Error generating model response: exception: access violation writing 0x0000000000005140, which seems to be indicative of an access violation...
| |