Operator Overload question for VB 2005

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

I am creating a class with operator overloads. It makes references to another
class I've created, but do not wish to modify. I try to overload an operator
having arguments having the other class type, but none of the new class type.
However it does return a type of the new class. The compiler tells me that at
least one parameter must be of the containing type. Is there a way to do
this? The other class hos no reference to this new class. Is there a way to
overload operators in the other class within the definition for the new
class? The overload I'm trying to create does not conflict with existing
overloads in the other class.
 
bsaucer
It sounds like you created two classes, correct?

And you want to create an overloaded operator that expects one class &
returns the second, correct?

Have you tried:

' VB.NET 2005 syntax

Public Class FirstClass
End Class

Public Class OtherClass
Public Shared Operator +(ByVal otherClass1 As OtherClass, ByVal
otherClass2 As OtherClass) As FirstClass
End Operator
End Class

Note the overloaded operator is in the class that the parameters are, not
the class of the return type.

Hope this helps
Jay
 
The problem is, the "other class" (written first) has no "knowledge" of the
new class. The new class does have knowledge of the older class.
Theoretically, the old class is "off limits", as if it were written by
someone else while I develop the new class.

I have found a workaround: I used a "widening ctype" operator in my new
class to allow the calling routine to use arguments of the other class, so I
no longer need to to overload all my arithmetic operators specifying the
other arguments.
 
bsaucer,
The problem is, the "other class" (written first) has no "knowledge" of
the
new class.
Click to expand...
Ah! there's the rub!
I have found a workaround: I used a "widening ctype" operator in my new
Click to expand...
Just be aware that a "widening ctype" operator may cause implicit
conversions when you do least expect them! (for example during an assignment
or being passed as a parameter to another method (other then one of your
overloaded operators).

If possible I would modify the "other class"! to avoid the implicit
conversions!

For example:

The DateTime operator - returns a TimeSpan, TimeSpan does not have an
implicit ("widening ctype") from DateTime. As a "widening ctype" on TimeSpan
from DateTime could cause lose of the Date part of the DateTime. TimeSpan
could have a narrowing ctype as TimeSpan represents less data then
DateTime...

NOTE: There are times when implicit conversions do make sense, such as an
implicit conversion from Double to Complex (where Complex is a type that
represents a complex number).

Hope this helps
Jay
 
Your note describes the situation, where an object of the original class CAN
be "upgraded" to the new class. I was going to use that anyway. I was just
surprised that it enabled me to eliminate several "redundant" operator
overloads!
NOTE: There are times when implicit conversions do make sense, such as an
implicit conversion from Double to Complex (where Complex is a type that
represents a complex number).
Click to expand...

Note that the double class has no "knowledge" of complex numbers, and
therefore makes no references to the complex class. However, the complex
class would make heavy use of doubles. You shouldn't have to modify the class
of doubles in any way to accomodate complex numbers.
 
bsaucer,
Your note describes the situation, where an object of the original class
CAN
be "upgraded" to the new class.
Click to expand...
I don't follow what you mean by "CAN be "upgraded"", do you mean an implicit
conversion is "well defined" between the two classes?
Note that the double class has no "knowledge" of complex numbers, and
Click to expand...
Correct, the double class has *NO* knowledge of complex numbers! You add or
subtract (or any other operator) two double numbers together and you still
have a double!

However defining an implicit conversion from Double to Complex makes sense
as its "well defined".

Where as in the case of DateTime if you subtract two DateTimes you have a
TimeSpan, its doesn't completely make sense to define the result of
subtracting two DateTimes in the terms of a DateTime (as you actually have a
duration & not an actual DateTime, hence the TimeSpan type)...

Likewise implicitly converting a DateTime to or from a TimeSpan does not
really make sense either.

NOTE: I'm not saying its wrong to have the implicit conversion, I'm just
saying make sure the implicit conversion makes sense in all cases... Those
cases are, but not limited to, assignments & parameter passing.

Hope this helps
Jay
 
Back
Top