On 21/01/12 01:42, Andrew Douglas Pitonyak wrote:
so, in general terms I can accept that subtraction will result in either a Date or a Double ( depending on whether one or both sides of the operation are Dates ). I can also accept that adding a number to a Date should result in a Date also makes sense. I have more difficulty understanding why adding 2 dates should give a Date as a result and am (like you) a little uncomfortable about the lack of symmetry regarding treatment of '-/+'. However, having an overriding rule that ensures any '+' operation involving a Date type results in a Date type does ensure that those operations you mentioned previously e.g. something likeI believe that you intend to cause the following behavior: date + num Date date - num Date date * num Double date / num Double date + date Date [2] date - date Double [3] date * date Double [2] - I prefer this, but I would not spend much energy advocating it.[3] - I would have subtraction return the same type as addition. So, if "date + date" returns "date", then I would return date for [3]. If you have [2] return a double, then have [3] return a double.My opinion is that you now just pick one and do it. I will call it a consensus and back your decision in the unlikely event I am ever called upon to do so.
Date1 + num + Date2
will result in a Date type maybe explains the reason for this lack of
symmetry in the treatment of '+/-'. Anyway since I can't make anymore
sense of this I prefer to defer to both the previous behaviour ( and
additionally behavriour of mso vba ) and modify the behaviour in the
minimum way, e.g. just change the behaviour of Date - 'num' to return a
Date. So, I will commit a change to provide the behaviour as is
described in the table above ( including the asymmetric treatment of +/-
). That's not to say we couldn't or shouldn't change the behaviour of
'+' later, just right now I am not comfortable with doing that.
Noel