TimeSpan / 2

[Michael C]

IS there a reason Timespan doesn't have an operator for divide? Being that
it's an amount of time I would have thought it should. Really it's just a
wrapper around a double variable?

Thanks,
Michael

 

[Nicholas Paldino [.NET/C# MVP]]

Michael,

It's not really a wrapper around a double variable. More like a 64 bit
integer.

You can always get the value of the Ticks property, divide it by two,
and create a new TimeSpan instance from that.

 

[Michael C]

Michael,

It's not really a wrapper around a double variable. More like a 64 bit
integer.

Good point.

You can always get the value of the Ticks property, divide it by two,
and create a new TimeSpan instance from that.

Yes, in my case I just got total seconds and divided by 2 but I'm still
curious as to why there is no operator for divide. I guess seeing no one
came up with a reason that means the reason is MS simply forgot.

Michael

 

[Peter Duniho]

[...] I guess seeing no one
came up with a reason that means the reason is MS simply forgot.

At best, it means that no one reading your post knows the answer.

You can't infer anything about the actual reason from a lack of responses.

Pete

 

[Michael C]

At best, it means that no one reading your post knows the answer.

Got a reason then?

 

[Peter Duniho]

Got a reason then?

Why do I need an answer to the question just to point out that there's no
way (at present) to know the answer to the question? What would the point
be in pointing out that we don't know the reason if I actually knew the
reason?

 

[Michael C]

Why do I need an answer to the question just to point out that there's no
way (at present) to know the answer to the question? What would the point
be in pointing out that we don't know the reason if I actually knew the
reason?

Well, I'm sure if there was a reason a smart guy like you would know it.

 

[Peter Duniho]

Well, I'm sure if there was a reason a smart guy like you would know it.

Well, you're wrong. There's lots of stuff I don't know, especially when
it comes to the design choices regarding the implementation of .NET.

 

[Michael C]

Well, you're wrong. There's lots of stuff I don't know, especially when
it comes to the design choices regarding the implementation of .NET.

Maybe so, but if a group of several thousand people can't even hint at a
reason then I suggest none exist.

Michael

 

[Stephany Young]

Did the elf at Redmond that designed the Timespan class consult you on what
operators it might or not need. I don't think so somehow.

He certainly didn't consult me and I pretty certain he didn't consult Peter
either.

If your life will really be enhanced that much by knowing the exact reason
then track down the elf in question and ask him.

 

[Peter Duniho]

Maybe so, but if a group of several thousand people can't even hint at a
reason then I suggest none exist.

Even if you assume there are several thousand people reading this
newsgroup on a regular basis (and frankly, that seems optimistic by a long
shot), there are definitely not several thousand people who would ever
post a reply to a question in this newsgroup.

I can certainly hypothesize about a reason, but whatever hypothesis I come
up with is irrelevant (and frankly, if history is any indication, is only
going to lead to pointless bickering about the validity of the
hypothesis). Why bother posting irrelevancies?

Even so, I still think it's premature to make an assumption that the
designers of the TimeSpan class simply "forgot".

Pete

 

[Chris Shepherd]

Yes, in my case I just got total seconds and divided by 2 but I'm still
curious as to why there is no operator for divide. I guess seeing no one
came up with a reason that means the reason is MS simply forgot.

I am with Peter on this, just because it wasn't done doesn't mean they forgot.

The possibility which makes the most sense to me relates to code clarity. Making
you use a property of the TimeSpan makes it perfectly clear what property you
are doing the math on, and what your expected result would be.

I'm not saying it's a perfect reason to not do it, I'm just guessing and don't
know any more than the people who have already spoken up.


Chris.

 

[Bill Butler]

Got a reason then?

Sure,
It is probably not a common usage and there are easy mechanisms (as you
found) to achieve the same thing.
A solidly designed class should not be a Swiss army knife with
attachments for every possible use it might be used for.

I find that Item 18 of "Effective C++" by Scott Meyers addresses this
point particularly well.

Item 18: Strive for class interfaces that are complete and Minimal

Bill

 

[Michael C]

I can certainly hypothesize about a reason, but whatever hypothesis I come
up with is irrelevant (and frankly, if history is any indication, is only
going to lead to pointless bickering about the validity of the
hypothesis). Why bother posting irrelevancies?

Then don't bicker as you always seem to. Post your reasons instead of
spending 10 posts saying they don't exist.

 

[Peter Duniho]

Then don't bicker as you always seem to. Post your reasons instead of
spending 10 posts saying they don't exist.

I didn't even write a single post saying they don't exist, never mind ten.

I'm sorry you think I'm bickering. My only point is that you've made the
assumption that the .NET team simply forgot to include this overloaded
operator, that you made the assumption on the sole basis of the lack of
replies here regarding other possibilities, and that your assumption on
that basis is unfounded.

You turned that statement into something else entirely, and proceeded down
a complete tangent. Even now, I don't understand why you write "post your
reasons", given that I made it very clear that I believe that no matter
what speculation I might make, there's not really any point in posting it
here.

Why you couldn't just acknowledge the erroneous conclusion you made and
leave it at that, I have no idea.

Pete

 

[Michael C]

I didn't even write a single post saying they don't exist, never mind ten.

Count up the number of posts between here and when I asked you if you had a
reason.

I'm sorry you think I'm bickering.

I must say I find the "Sorry if you think I'm ...." line funny whenever I
hear it.

My only point is that you've made the assumption that the .NET team
simply forgot to include this overloaded operator, that you made the
assumption on the sole basis of the lack of replies here regarding other
possibilities, and that your assumption on that basis is unfounded.

That was not the sole reason. I also based this on the fact that it would be
useful and makes a lot of sense. TimeSpan is a fairly basic unit of measure
and to multiply or divide it by another number is as natural as dividing
metres or volume by an integer.

You turned that statement into something else entirely, and proceeded down
a complete tangent. Even now, I don't understand why you write "post your
reasons", given that I made it very clear that I believe that no matter
what speculation I might make, there's not really any point in posting it
here.

Just post your reasons ffs.

Why you couldn't just acknowledge the erroneous conclusion you made and
leave it at that, I have no idea.

Possibly because I don't agree with you.

Michael

 

[Michael C]

Sure,
It is probably not a common usage

I think that dividing or multiplying a length of time by an integer is a
fairly common usage.

and there are easy mechanisms (as you found) to achieve the same thing.

True but that could be said of a lot of things that have been included. We
have an operator to subtract one timespan from another but that could be
achieved other ways.

A solidly designed class should not be a Swiss army knife with attachments
for every possible use it might be used for.

I find that Item 18 of "Effective C++" by Scott Meyers addresses this
point particularly well.

Item 18: Strive for class interfaces that are complete and Minimal

That makes sense although it is a gray line exactly where you stop. I don't
see anything wrong in added a few conveniences. I think if you took "Item
18" (sounds very official literally we'd have more difficult to use
classes.

Michael

 

[Michael C]

I am with Peter on this, just because it wasn't done doesn't mean they
forgot.

The possibility which makes the most sense to me relates to code clarity.
Making you use a property of the TimeSpan makes it perfectly clear what
property you are doing the math on, and what your expected result would
be.

I'm not saying it's a perfect reason to not do it, I'm just guessing and
don't know any more than the people who have already spoken up.

To me it made such perfect sense that I went and coded it fully expecting it
to work. I was quite suprised some time later to get a compile error. The
alternative:

TimeSpan ts2 = new TimeSpan(ts1.Ticks / 2)

appears much more complicated and although I presume that is the correct way
to do it I'm still not certain. Should I convert it to Milliseconds and back
or maybe seconds? Should I be using a double variable or an integer or long?

The only thing I can think of is that doing "ts1 / 2" it's not clear how it
will round but I don't think that's much of an issue. Obviously programmers
will expect it to have a certain level of resolution and that dividing by 2
could cause some minor loss of information.

Michael

 

[Peter Duniho]

Count up the number of posts between here and when I asked you if you
had a
reason.

I count four posts by me, none of which include a statement that there is
no reason.

Even if they _all_ included such a statement, your "ten" is wildly
inaccurate, and given that the actual number is _zero_ posts containing
the statement, your claim of "ten" is ridiculous.

That was not the sole reason.

Well, it was the only basis you offered. I quote: "I guess seeing no one
came up with a reason that means the reason is MS simply forgot." And it
was that statement that I took issue with, no other.

It's unfortunate that you can't just accept that and move on. But I'm not
interested in wasting any more time reiterating the obviously incorrect
nature of the statement to which I replied. Nor do I see any point in
having a discussion with someone who chooses to characterize my statements
as "bickering".

If you want to have a civil discussion about the whys and why nots of an
operator overload, you let us know. In the meantime, it's pretty obvious
that you're not going to be happy with any reply that is anything less
than a full agreement with your dissatisfaction with the TimeSpan class's
interface. There's really no point in carrying on with someone acting
that way.

Pete

 

[Bill Butler]

I think that dividing or multiplying a length of time by an integer is
a fairly common usage.

Really?!? Not in my experience.
But, then again it could just be the areas we are working in that give
us a different outlook.

While I could envision reasons for multiplying/dividing a Timestamp by a
number, I would hardly think they were common. What are you doing with
Timespans that makes this an attractive feature?

True but that could be said of a lot of things that have been
included. We have an operator to subtract one timespan from another
but that could be achieved other ways.

That makes sense although it is a gray line exactly where you stop. I
don't see anything wrong in added a few conveniences. I think if you
took "Item 18" (sounds very official literally we'd have more
difficult to use classes.

Absolutely, if you are too restrictive, you can make hard to use
classes.

I was just trying to offer a reason (besides forgetfulness) why
multiplication/division might be left out of the class.
The existing TimeSpan was designed to go hand in hand with Datetime
arithmetic.
Addition, Subtraction, hours, minutes, seconds all feel natural to this
class.
Multiplication/Division by a constant feels more like an attempt to do
math with units
miles/hour
meters/sec^2

In that case the timespan class is not really a good fit either.


Just my 2 cents
Bill