Place it in a safe that has a 4 digit PIN pad on the front.
"Life should not be a journey to the grave with the intention of arriving safely in a pretty and well preserved body, but rather to skid in broadside in a cloud of smoke, thoroughly used up, totally worn out, and loudly proclaiming "Wow! What a Ride!"
— Hunter S. Thompson
i face following problem in publishing the website.
Error 97 The type 'IqSiteWeb.CustomControls.DonationAgencyList' exists in both 'c:\Users\dell\AppData\Local\Temp\Temporary ASP.NET Files\iqsiteweb\5dc5d18b\b10a84ef\App_Web_jhddkwxc.dll' and 'c:\Users\dell\AppData\Local\Temp\Temporary ASP.NET Files\iqsiteweb\5dc5d18b\b10a84ef\App_Web_utdgqfe5.dll' C:\ProjectList\Kei Versions\KEI-WebSite\IqSiteWeb\Donation\DonationView.aspx 33
i tried a lot to surf the net and get the solution but i dint get any solid solution......
I have written a few classes to handle geometry primitives, like Length, Angle, etc, to make sure there are no unit mismatches as could happen if the values are stored in plain double types.
Coming from C++, I overloaded operator== et al, to compare the actual values, which to me would be intuitive. However, co-workers coming from Java claimed operator== should be reserved for comparing references, and that I should use Equal() and the like for comparison. The C#-ers here seems to be divided.
Is there a design guide for operator overloading in C#? How would you prefer the implementation? Operator overloading or plain old function calls?
I think there is not a clear rule for this. If you overload the other relational operators (<, > <=, >=) then I think that overloading == for bit equality makes sense. Rememeber you can always use the static method Object.ReferenceEquals to compare references.
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.
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.
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.
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.
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.
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.