|
You could always use Object.ReferenceEquals..
But, in my opinion, types like Length and Angle etc should be value types (and therefore structs, unlike in C++, in C# classes can never be value types) - they represent a value instead of a thing and in almost every situation will it be more intuitive if they also behave like values.
To counter his argument:
1) C# is not Java
2) operator== on strings compares for value-equality (even when you make sure that string-interning is avoided)
|
|
|
|
|
As long as it is clear in the documentation for your class that == does value equality checking, and that makes sense for how the class would normally be used, it is fine to do that in .Net. As mentioned below, string.== does that.
However, I also agree with the comment below that simple wrappers like that should be value types (structs).
Edit: Below=above. I forgot which way CP forums stack posts.
|
|
|
|
|
Niklas Lindquist wrote: co-workers coming from Java claimed operator== should be reserved for comparing
references
That's because Java got it wrong and they want to share the misery.
Use == for value equality in .net; it's right way, the intuitive way.
|
|
|
|
|
PIEBALDconsult wrote: That's because Java got it wrong and they want to share the misery.
Having seen some truly hideous usages of operator overloading including at least one that I wrote myself and having never seen any truly inspired usage of the same I would say that Java got it right.
So in terms of misery the win goes to C++.
|
|
|
|
|
jschell wrote: truly hideous usages of operator overloading
I would say that that describes Java. 
C and C# are the only languages I consider.
|
|
|
|
|
PIEBALDconsult wrote: C and C# are the only languages I consider.
Myself I use languages that are appropriate for the job.
Those include C++, C#, Java, SQL (vendor specific implementations), Perl and various OS scripting languages.
Myself I wouldn't use C versus C++ unless forced.
Small differences in one language do not matter in terms of choice over another.
|
|
|
|
|
You can abuse almost any language feature..
The "no operator overloading" along with the "no structs" (though that one is not as bad) restrictions make it impossible to create proper new numeric types in Java, and that just sucks. It makes the predefined types more magic, and it makes working with any non-predefined numeric type a pain.
As for the abuse, sure, you can do that. You can also have overloads Foo(int) and Foo(long) and have them do something completely different - that's on the same level as operator overloading abuse, but Java still allows that. You can also override some method (accidentally even, in Java) and have it completely break the Liskov substitution principle.
|
|
|
|
|
David1987 wrote: The "no operator overloading" along with the "no structs" (though that one is
not as bad) restrictions make it impossible to create proper new numeric types
in Java, and that just sucks. It makes the predefined types more magic, and it
makes working with any non-predefined numeric type a pain.
Since the vast majority of programming in the world does not involve that it isn't a significant problem.
And since most programs that do deal with specialized numerics often have other requirements, such as performance and or significant other functionality (non-numeric) then one should either choose an appropriate language or live with the small amount of code that java entails.
The obvious analogy to that is that SQL is very poor candiate for string manipulation and regexes and thus applications used widely, such as editors, should not be written in SQL. That however doesn't mean that SQL suffers because of it.
David1987 wrote: As for the abuse, sure, you can do that. You can also have overloads Foo(int)
and Foo(long) and have them do something completely different - that's on the
same level as operator overloading abuse, but Java still allows that. You can
also override some method (accidentally even, in Java) and have it completely
break the Liskov substitution principle.
No.
It is not a question of whether abuse can happen.
The point is that it does happen.
Enough so that me and others have seen it.
And it is not accidental.
|
|
|
|
|
Congratulations, you are a troll.
|
|
|
|
|
David1987 wrote: Congratulations, you are a troll.
I see...so expressing my opinion makes me a troll while you expressing yours is just the thoughtful insight of a recognized genius?
|
|
|
|
|
It does when you're dismissing arguments out of hand and using irrelevant and nonsensical arguments to "prove" your position.
This post again proves you to be a troll.
|
|
|
|
|
|
Indeed they were not. It's not the only mistake they made. The C# creators disagreed with them.
|
|
|
|
|
David1987 wrote: It's not the only mistake they made.
Your opinion.
David1987 wrote: The C# creators disagreed with them.
Actually your opinion as well. The existence of the idiom in the language itself is not proof of your opinion. Now if you can provide a documented reference that states specifically that it was added because Java didn't have it (versus say because C++ does) then that would certainly be relevent.
Relevent of their opinion though and nothing else.
|
|
|
|
|
No. You're just talking crap here.
They didn't choose to leave operator overloading out, so they can't have seen it as a major problem.
It doesn't matter whether they specifically added it because Java didn't have it - it matters that they didn't see it as a problem. Their disagreement doesn't have to be explicit to be disagreement.
|
|
|
|
|
You specifically said.
"The C# creators disagreed with them."
That suggests intent.
1. They looked at Java, it didn't have operator overloading and thus they added it because Java didn't have it. In this case they disagreed with the the designers of Java.
2. Conversely they could have looked at C++, saw that it had operator overloading and added it because of that. In this case they agreed with the designers of C++.
1 and 2 are not the same.
|
|
|
|
|
No it does not. It means they don't share the same opinion.
|
|
|
|
|
David1987 wrote: No it does not. It means they don't share the same opinion.
Which is not the same as your previous statement when you said "The C# creators disagreed with them."
|
|
|
|
|
Also in case you hadn't noticed, a post like that is the mark of a troll. There is no doubt about it. You are purposefully wasting my time with your intentional nonsense.
|
|
|
|
|
David1987 wrote: Also in case you hadn't noticed, a post like that is the mark of a troll. There
is no doubt about it. You are purposefully wasting my time with your intentional
nonsense.
Because you said it, it must be so.
Couldn't possibly be because I disagree with your opinion.
|
|
|
|
|
Ok I'm bored so I'm going to argue anyway.
jschell wrote: Since the vast majority of programming in the world does not involve that it isn't a significant problem.
Not sure what world you're living in. Every time a vector or a int128 (or larger) is needed, Java will make your life a hell by insisting on manual cloning and writing verbose a.Multiply(b) and the like, for no reason other than that operator overloading can and is abused. Frankly it's none of their busyness whether I choose to abuse their language or not.
But then again maybe you're working for some boring company just maintaining even more boring applications (as they call them, versus actual programs) - you know, the kind of program that doesn't actually do anything but just glues some stuff together.
jschell wrote: And it is not accidental.
Of course it isn't. I was referring to overloading methods in Java, which you can do accidentally because it doesn't require any syntax. It also will happen sooner or later and that's a nasty bug which is hard to find.
You can also override some method (accidentally even, in Java) and have it completely break the Liskov substitution principle.
People will do it, on purpose too. So lets ban virtual methods.
In fact, let's ban strings and IO and arrays and dictionaries and floating point numbers and abstract classes and definitely reflection, all of which are frequently abused.
|
|
|
|
|
David1987 wrote: Not sure what world you're living in. Every time a vector or a int128 (or larger) is needed, Java will make your life a hell by insisting on manual cloning and writing verbose a.Multiply(b) and the like, for no reason other than that operator overloading can and is abused. Frankly it's none of their busyness whether I choose to abuse their language or not.
Presumably you mean 'vector' in terms of mathematics and not in terms of the java class.
Based on that, the point is meaningless. In terms of lines of code in the world the code that requires vectors is so small as to be unmeasurable.
David1987 wrote: But then again maybe you're working for some boring company just maintaining even more boring applications (as they call them, versus actual programs) - you know, the kind of program that doesn't actually do anything but just glues some stuff together
Not sure what that means but most of the applications I write do glue things together. And they also make a lot of money both directly and indirectly.
I will admit that getting a regular paycheck and being able to pay bills is in fact 'boring' compared to the alternative. Applications that make money lead to that sort of boredom.
David1987 wrote: Of course it isn't. I was referring to overloading methods in Java, which you can do accidentally because it doesn't require any syntax. It also will happen sooner or later and that's a nasty bug which is hard to find.
I don't recall it happening to me. I do recall hundreds, thousands, perhaps hundreds of thousands of logic errors of which many are in fact hard to diagnose and sometimes very hard to solve. So I suspect the one of which you speak is lost in the noise.
David1987 wrote: People will do it, on purpose too. So lets ban virtual methods.
I haven't seen many problems with that in java. I can't recall any. I saw more of that sort of problem in C++ with people not understanding such things as the role of a virtual dtor.
And working around the lack of virtual methods can be done but is much harder.
David1987 wrote: In fact, let's ban strings and IO and arrays and dictionaries and floating point numbers and abstract classes and definitely reflection, all of which are frequently abused.
Which again ignores my point.
Operator overloading is often misused. And misused despite there being alternatives.
That isn't true for your examples.
1. Situations exist which those are the only solution. And alternatives are hard or impossible.
2. The incorrect usage compared to correct usage is much more reasonable than versus operator overloading.
|
|
|
|
|
Strings and floats and reflection are very often abused. Enough so that I see such abuses pop up in the C# forum about every few weeks or so.
But operator overloading abuse? Never in C#.. sometimes in C++, which sets the wrong example with their << on streams - and still less often than string-abuse.
String abuse is especially bad since it causes performance trouble real quick - as does Object abuse, which I hadn't even previously mentioned (some people seem to think that you have to wrap everything in an object).
jschell wrote: Based on that, the point is meaningless. In terms of lines of code in the world the code that requires vectors is so small as to be unmeasurable.
Sure, you can put everything on one line.. which is a different kind of abuse, also made possible by java, but easily defeatable with auto-formatting.
The raytracer we had to write in University became a horror of tangles Subtract's and Multiply's that in no way looked like the actual formula's. It sucked. With operator overloading it wouldn't have been such a pain.
jschell wrote: Operator overloading is often misused.
Prove it. I've never seen it.
|
|
|
|
|
David1987 wrote: Strings and floats and reflection are very often abused. Enough so that I see such abuses pop up in the C# forum about every few weeks or so.
That is not evidence that in total lines of code that it occurs 'often'.
And you see Strings misused?
David1987 wrote: String abuse is especially bad since it causes performance trouble real quick
I have seen claims of that. And hypothetical arguments about it. I have never seen it occur in a real application.
Presumably you have. Could you describe the nature of that problem and the impact on the application performance pre and post?
David1987 wrote: Sure, you can put everything on one line.. which is a different kind of abuse, also made possible by java, but easily defeatable with auto-formatting.
That isn't what I meant.
Given a count of lines of code in the world for all languages, the number of lines of code involving vectors (mathematical) is so small that one is unlikely to be able to measure it enough to get it above the error rate of the measurement process itself.
David1987 wrote: The raytracer we had to write in University became a horror of tangles Subtract's and Multiply's that in no way looked like the actual formula's. It sucked. With operator overloading it wouldn't have been such a pain.
Since most of OO programming involves method calls why is this different than any other OO programming task?
Or misusing some other OO idiom such as method chaining.
And how many total code lines were in the application? And how many code lines were specific to vector arithmetic operations?
David1987 wrote: Prove it. I've never seen it.
Then here you go...
http://thedailywtf.com/Comments/Yet-Another-Operator-Overloading-Abuse.aspx?pg=4[^]
|
|
|
|
|
jschell wrote:
Presumably you have. Could you describe the nature of that problem and the impact on the application performance pre and post?
No.
All programs I've actually worked on were written either by just myself or me and a bunch of friends all of whom are not noobs who use strings for everything. There was no operator overloading abuse either.
See here[^] for the worst string abuse I can remember from this forum.
jschell wrote: Then here you go...
Yes, it's C++.
Argument dismissed.
C++ has operator overloading abuse built-in with their << on streams.
And besides, we were talking about C#.
jschell wrote: Given a count of lines of code in the world for all languages, the number of lines of code involving vectors (mathematical) is so small that one is unlikely to be able to measure it enough to get it above the error rate of the measurement process itself.
That doesn't matter (though there are definitely a lot in scientific code - if we ignore the Boring Code that becomes a lot more significant). Vectors aren't the only thing that should behave like a mathematical type instead of objects.
jschell wrote: Since most of OO programming involves method calls why is this different than any other OO programming task? Or misusing some other OO idiom such as method chaining.
Because a vector shouldn't be modeled as an object. A vector is a value, so that's exactly what it should be modeled as.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
