Compare Timespan Values

[Russ Green]

How does this:
public TimeSpan Timeout
{
get { return timeout; }
set
{
timeout = value;
if(timeout < licenseTimeout)
licenseTimeout = timeout;
}
}
private TimeSpan timeout = TimeSpan.FromMinutes(10);

Convert to VB.NET when in VB.NET Opertor '<' is not defined for types
'Sysem.TimeSpan' and System.TimeSpan'


TIA

Russ

 

[Guest]

You can use the CompareTo method of TimeSpan this 'will compare two TimeSpans

 

[Cor Ligthert]

Russ,

Make it yourself easy, you can in datetime and timespan forever compare the
ticks.

However, not when it is a by by instance a by a datetimepicker set date,
than you have to do it in another way.

But in your case I think that it is the way to go.

I hope this helps,

Cor

 

[Jay B. Harlow [MVP - Outlook]]

Russ,
Rather then ask specifically how to Compare two TimeSpan values I normally
ask how to Compare any two values in .NET.

Values that are comparable in .NET either override Object.Equals for
identity Equals or implement the IComparable interface. Classes that
override Object.Equals or Implement IComparable also normally override the
=, <>, <, <=, >, and >= operators. Unfortunately VB.NET 2002 & 2003 do not
directly support overloaded operators, instead you need to explicitly call
the routine (in the case of = operator the routine is op_Equality, see
"Operator Overloading Usage Guidelines" listed below. VS.NET 2005 (aka
Whidbey, due out later in 2005, http://lab.msdn.microsoft.com/vs2005/) will
support using & defining overloaded operators.

So in the case of TimeSpan I can simply call TimeSpan.Compare or
TimeSpan.CompareTo to compare TimeSpan Values.

Using Equals, Compare, or CompareTo allows my code to be consistent across
all types, rather then needing to remember what property or properties I
need use for each type. For example, if I had a Person type I can simply
call Person.Compare, rather then needing to remember what set of attributes
(properties) of the Person class. Of course the danger of comparing sets of
attributes/properties is code duplication, by calling Person.Compare the
comparison itself is neatly encapsulated in the Person object. Further the
Compare routine is polymorphic, in that each type has its own Compare... Of
course with VS.NET 2005 we will have overloaded operators so I can simply
use the overloaded operators...

I would not rely on comparing Ticks or other properties as that IMHO is an
"oddball solution", an "Oddball Solution" is when you have two or more
similar constructs (comparing objects) & you do it two or more different
ways (DateTime.Ticks, Person.Name). "Oddball Solution" is a "code smell"
that is identified in "Refactoring to Patterns"
http://www.industriallogic.com/xp/refactoring/.

There was a long discussion a few months back in this group on using =
operators or the Equals method titled "Comparing Empty Value Types" from
about November 17, 2004. See the entire thread starting with:

http://groups-beta.google.com/group...06b2e/9752a3ff291c3f36?hl=en#9752a3ff291c3f36


For a list of commonly overloaded Operators & the alternative methods see
"Operator Overloading Usage Guidelines" at:
http://msdn.microsoft.com/library/d...l/cpconOperatorOverloadingUsageGuidelines.asp

IComparable:
http://msdn.microsoft.com/library/d...ref/html/frlrfSystemIComparableClassTopic.asp

Object.Equals:
http://msdn.microsoft.com/library/d...f/html/frlrfSystemObjectClassEqualsTopic1.asp

http://msdn.microsoft.com/library/d...nref/html/cpconImplementingEqualsOperator.asp

Hope this helps
Jay

| How does this:
| public TimeSpan Timeout
| {
| get { return timeout; }
| set
| {
| timeout = value;
| if(timeout < licenseTimeout)
| licenseTimeout = timeout;
| }
| }
| private TimeSpan timeout = TimeSpan.FromMinutes(10);
|
| Convert to VB.NET when in VB.NET Opertor '<' is not defined for types
| 'Sysem.TimeSpan' and System.TimeSpan'
|
|
| TIA
|
| Russ
|
|

 

[Jon Skeet [C# MVP]]

Using Equals, Compare, or CompareTo allows my code to be consistent across
all types, rather then needing to remember what property or properties I
need use for each type.

Does that mean you use them for Int32 (etc) as well? If not, where do
you draw the line?

 

[Jay B. Harlow [MVP - Outlook]]

Jon,
Although I don't state it, I thought it was easily inferred:

First choice is the = operator on the values themselves (not properties of
the values). Seeing as VB.NET supports the = operator on both Int32 &
DateTime, I use the = operator.

Unfortunately VB.NET 2002 & 2003 does not support overloaded operators, so I
"fall back" to the Equals method, rather then risk duplicate code by using
one or more properties of the values. Of course in VB.NET 2005 overloaded
operators are supported, ergo I will use the overloaded = operator. Unless I
am working on a polymorphic routine where Object.Equals, IEquatable(Of T),
IComparable, or IComparable(Of T) make more sense, then I would use one of
these Interfaces or Object.Equals instead...

Seeing as C# does support overloading the = operator, in C# I would favor
the = operator...

The point I am attempting to make is that IMHO its better to compare the
values/objects themselves, rather then rely on comparing
attributes/properties of the said values/objects.

Hope this helps
Jay

| > Using Equals, Compare, or CompareTo allows my code to be consistent
across
| > all types, rather then needing to remember what property or properties I
| > need use for each type.
|
| Does that mean you use them for Int32 (etc) as well? If not, where do
| you draw the line?
|
| --
| Jon Skeet - <[email protected]>
| http://www.pobox.com/~skeet
| If replying to the group, please do not mail me too

 

[Jay B. Harlow [MVP - Outlook]]

Doh!

Of course types that don't actually override Object.Equals nor implement one
of IEquatable(Of T), IComparable, or IComparable(Of T), nor overload any of
the comparison operators then of course, as a last resort, I would compare
specific attributes/properties. Especially is it was a type I could not
modify... Of course I would consider encapsulating this comparison in a
Comparer object (Singleton?) to minimize duplicate code...

Jay

| Jon,
| Although I don't state it, I thought it was easily inferred:
|
| First choice is the = operator on the values themselves (not properties of
| the values). Seeing as VB.NET supports the = operator on both Int32 &
| DateTime, I use the = operator.
|
| Unfortunately VB.NET 2002 & 2003 does not support overloaded operators, so
I
| "fall back" to the Equals method, rather then risk duplicate code by using
| one or more properties of the values. Of course in VB.NET 2005 overloaded
| operators are supported, ergo I will use the overloaded = operator. Unless
I
| am working on a polymorphic routine where Object.Equals, IEquatable(Of T),
| IComparable, or IComparable(Of T) make more sense, then I would use one of
| these Interfaces or Object.Equals instead...
|
| Seeing as C# does support overloading the = operator, in C# I would favor
| the = operator...
|
| The point I am attempting to make is that IMHO its better to compare the
| values/objects themselves, rather then rely on comparing
| attributes/properties of the said values/objects.
|
| Hope this helps
| Jay
|
| || > Using Equals, Compare, or CompareTo allows my code to be consistent
| across
|| > all types, rather then needing to remember what property or properties
I
|| > need use for each type.
||
|| Does that mean you use them for Int32 (etc) as well? If not, where do
|| you draw the line?
||
|| --
|| Jon Skeet - <[email protected]>
|| http://www.pobox.com/~skeet
|| If replying to the group, please do not mail me too
|
|

 

[Jon Skeet [C# MVP]]

Although I don't state it, I thought it was easily inferred:

First choice is the = operator on the values themselves (not properties of
the values). Seeing as VB.NET supports the = operator on both Int32 &
DateTime, I use the = operator.

But doesn't that then go against:

<quote>
Using Equals, Compare, or CompareTo allows my code to be consistent
across all types, rather then needing to remember what property or
properties I need use for each type.
</quote>

I could understand a pattern which said "for all the primitive types,
use operators, but for all other types use Equals" but to use the
operator for DateTime goes against that. If it's okay to remember
DateTime, might there not be other value types it's worth remembering?

The point I am attempting to make is that IMHO its better to compare the
values/objects themselves, rather then rely on comparing
attributes/properties of the said values/objects.

Sure.

 

[Cor Ligthert]

Jay,

In my opinin is this the same discussion as the toArgb discussion.

Although in this case is the difference in the problem, that your for the
colours very valid point, that you want be more clear in the code, about
what colours you are talking, is less important. You only want to know if
date "A" was before or after date "B" or that the time difference between
"A" and "B" was equal, higher or less from each other.

Just my opinion.

Cor

 

[Jay B. Harlow [MVP - Outlook]]

Cor,
| In my opining is this the same discussion as the toArgb discussion.
Yes, that's why I referenced the ToArgb discussion.

Jay

| Jay,
|
| In my opinin is this the same discussion as the toArgb discussion.
|
| Although in this case is the difference in the problem, that your for the
| colours very valid point, that you want be more clear in the code, about
| what colours you are talking, is less important. You only want to know if
| date "A" was before or after date "B" or that the time difference between
| "A" and "B" was equal, higher or less from each other.
|
| Just my opinion.
|
| Cor
|
|

 

[Jay B. Harlow [MVP - Outlook]]

Jon,
Not really:

The pattern (I use) is "For all types that support operators use operators,
but for all other types use Equals...".

Although I didn't state it, my original post was in the context of the
operators are not available, as the original poster indicated the operators
are not available. So I don't see any conflict. Looking back I probably
should have included that in my original post.

Hope this helps
Jay


| > Although I don't state it, I thought it was easily inferred:
| >
| > First choice is the = operator on the values themselves (not properties
of
| > the values). Seeing as VB.NET supports the = operator on both Int32 &
| > DateTime, I use the = operator.
|
| But doesn't that then go against:
|
| <quote>
| Using Equals, Compare, or CompareTo allows my code to be consistent
| across all types, rather then needing to remember what property or
| properties I need use for each type.
| </quote>
|
| I could understand a pattern which said "for all the primitive types,
| use operators, but for all other types use Equals" but to use the
| operator for DateTime goes against that. If it's okay to remember
| DateTime, might there not be other value types it's worth remembering?
|
| > The point I am attempting to make is that IMHO its better to compare the
| > values/objects themselves, rather then rely on comparing
| > attributes/properties of the said values/objects.
|
| Sure.
|
| --
| Jon Skeet - <[email protected]>
| http://www.pobox.com/~skeet
| If replying to the group, please do not mail me too