Funny code

I personally wouldn't overload the == operator. Operator overloading isn't my style anyways, since it doesn't 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. I've never had any troubles with, only troubles without it. And it's soooo easy in the new VB. It just feels great to be able to do that in VB.
Visual Basic: 
        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:
mskeel said:
I've never had any troubles with, only troubles without it.
Click to expand...
I don't 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.

Visual Basic: 
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()

One thing that surprises me a little is that the << and >> operators aren't overloaded for streams.
 
marble_eater said:
Like I said, it is syntactical sugar.
Click to expand...
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 == doesn't get you going, but overlading + surely must. That's 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 aren't overloaded for streams.
Click to expand...
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 isn't 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 doesn't 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 can't perform a bitshift on a stream so there isn't any ambiguity. There is no conflict in C++ and I can't imagine that there would be in VB. To be perfectly honest, when streams were introduced in VB I didn't know what to do with them because they didn't overload the << and >> operators.

Visual Basic: 
Dim MySteam As New FileStream("C:\\Textfile.txt", FileMode.Open, FileAccess.Write)
MyStream << "There is no reason why we can't 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
 
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.
Click to expand...
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
Click to expand...
Not at all. I'll 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 wouldn't 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 aren't 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 don't 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 don't 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 don't, don't. If you overload Equals on a reference type (class), I don't care - just don't come work for me :)

-ner
 
Sorry, I didn't mean to hijack the thread.

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