Funny code

I personally wouldnt overload the == operator. Operator overloading isnt my style anyways, since it doesnt do anything but assign function calls to operators, it is really just syntactical sugar. (What is it at the IL level? Are the functions marked by flags? Or do they have special names like contructors?) But I can think of a dozen cases where you might want to overload the == operator on a class. For instance, if a class is instantiated with data loaded from a file, and you want to compare different instances for duplicate data, or if you have a class related to something like a domain name, registry key, or file, and want to check if objects refer to the same domain/key/file/etc.

I can see people doing it left and right, and then shooting themselves in the foot when they unwittingly call the == overload because they are trying to check for equal references.
 
Operator overloading is the king of cool, man. Ive never had any troubles with, only troubles without it. And its soooo easy in the new VB. It just feels great to be able to do that in VB.
Code:
        Public Shared Operator =(ByVal super1 As SuperObj, ByVal super2 As SuperObj) As Boolean
            If super1 Is Nothing AndAlso super2 Is Nothing Then
                Return True
            End If

            if super1 is nothing orelse pair2 is nothing then
                Return False
            End If
           
          If super1._string1 = super2._string1 AndAlso _
               super1._string2 = super2._string2 Then
                Return True
            End If

            Return False
        End Operator
        
         and now, the required not equals..
        Public Shared Operator <>(ByVal super1 As SuperObj, ByVal super2 As SuperObj) As Boolean
            Return Not (super1 = super2)
        End Operator
Looks like the message board needs to be updated for .Net 2.0 key words.
 
Last edited by a moderator:
mskeel said:
Ive never had any troubles with, only troubles without it.
I dont understand how you have trouble without operator overloads. Like I said, it is syntactical sugar. You just use operators instead of function names and the substitution is done for you at compile.

[VB]
Public Shared Function Equals(ByVal Super1 As SuperObj, ByVal Super2 As SuperObj) As Boolean
If Object.ReferenceEquals(Super1, Super2) Then Return True

If Super1 Is Nothing OrElse super2 Is Nothing Then
Return False
End If

If Super1._String1 = Super2._String1 AndAlso _
Super1._String2 = Super2._String2 Then
Return True
End If

Return False
End Function

and now, the not equals is not required... We can always use Not Equals()
[/VB]

One thing that surprises me a little is that the << and >> operators arent overloaded for streams.
 
marble_eater said:
Like I said, it is syntactical sugar.
Have you ever had sugar-free cookies? Maybe a friend with diabetes gave them to you. They taste terrible. I think sugar is absolutely necesary. You are more than welcome to code however you want (wordy), but with it being so convenient and easy, I see no reason not to overload the equals operator for most objects. Allright, so maybe overloading == doesnt get you going, but overlading + surely must. Thats pretty hard core, being able to simply add a custom class. Operator overloading is more than just sugar at that point.


marble_eater said:
One thing that surprises me a little is that the << and >> operators arent overloaded for streams.
Are these used for streams at all in VB.Net? I know they are in C++ and you can overload them in that context in that language. But they are also used for bitwise operations, so depending on the context they can mean different things.
 
Sugar free food still nourishes, and all that sugar isnt good for you. You need to get your energy from complex carbs. Maybe if your parents fed you better growing up, you would be able to appreciate sugar free cookies. Have some carrot sticks. But, yes, I have eaten sugar free everything because I know plenty of people who think that diet/fat-free/sugar-free food is the solution to a weight problem.

In all seriousness, syntactical sugar is ultimately just that. I make a distinction between something like anonymous methods, which, from an extreme point of view, could be considered syntactical sugar for extra classes with methods to pass as delegates, and something like operator overloading which makes a simple substitution of "opAddition" for a "+". Operator overloading does not really add or modify functionality. You can argue that it modifies the behavior of operators, but in reality it replaces operators with functions at compile time and doesnt really behave like an operator at all. It makes your code prettier with a simple modification of syntax but without a modification of the analogy between what your code says and what it actually does, hence the name syntactical sugar. It is nice, and I can appreciate it, but I would never ever call it necessary. I will never mind using a function named Add().

<< and >> are bitwise operators in C++, but they are overloaded and generally used for streams. Obviosly you cant perform a bitshift on a stream so there isnt any ambiguity. There is no conflict in C++ and I cant imagine that there would be in VB. To be perfectly honest, when streams were introduced in VB I didnt know what to do with them because they didnt overload the << and >> operators.

[VB]
Dim MySteam As New FileStream("C:\\Textfile.txt", FileMode.Open, FileAccess.Write)
MyStream << "There is no reason why we cant use << or >> on a stream."
MyStream << Environment.NewLine << "This is on the next line." << Environment.NewLine
MyStream << "Bitshift: 5 << 2" << (5 << 2)
That last one might hurt your head, but that is messy coding, not ambiguous operators
[/VB]
 
marble_eater said:
It makes your code prettier with a simple modification of syntax but without a modification of the analogy between what your code says and what it actually does, hence the name syntactical sugar.
By that logic, all higher level languages are "syntactical sugar". You could be the founding member of Xtreme Binary Talk! :D
 
mskeel said:
By that logic, all higher level languages are "syntactical sugar". You could be the founding member of Xtreme Binary Talk! :D
Not at all. Ill point out again that I make a distinction between something that performs an entirely new or significantly different function and something that is a minor syntax modification. The difference is, again, the analogy between what the code says and what it compiles to.

You have machine language and ASM. They are semantically very close. To describe the difference between the two as syntactical sugar wouldnt be entirely correct, though. The named commands are syntactical sugar (albeit very useful syntactical sugar). In that respect, a machine language coder with enough experience could equal an ASM programmer in terms of proficiency.

But ASM adds functional differences, such as labels, and new concepts like comments, modifying the analogy between the code that is written and the compiled result (I know, ASM and machine language arent compiled).

Up at the next level, C abstracts the process of coding to the point that it no longer resembles simple computer commands but rather a logical process that is structured and modular as well as applicable to any CPU instead of a specific CPU, and adds more new functions and concepts, like structs and macros. C++ extends that with polymorphism, inheritance and encapsulation. And then VB abstracts things further, looking more like written sentences than computer code. None of those differences are syntactical suger. They dont decorate code. They change what it does and what it can do. They make code able to describe function with increasing brevity or simplicity as you reach higher level languages. Then there are .Net languages and Java, which compile for a natively object-oriented platform, and there are standard libraries for the majority of languages, which dont come close to syntactical sugar in any sense of the word.

On the other hand, operator overloading is functionally identical to creating a function to add or compare. It is merely cosmetic, and that is the essence of syntactical sugar.
 
Whoa, Nellies! Funny Code was the topic - someone got sidetracked.

Let me sum it up: if you like operator overloading, use it. If you dont, dont. If you overload Equals on a reference type (class), I dont care - just dont come work for me :)

-ner
 
Sorry, I didnt mean to hijack the thread.

I think there is still some discussion to be had about operator overloading so Ive cranked up a new thread to continue that discussion and let this one get back on subject.
 
Back
Top