On 23/09/2014 08:48, Max Leske wrote:
On 19.09.2014, at 19:14, Mark Bestley <[email protected]> wrote:
On 19/09/2014 13:48, Max Leske wrote:
Ok, so I read Chris’ e-mail and I’m intrigued.
Sven, you’re still right about financial months being 30 days for instance but
the thing is that the current implementation seems broken (or inconsisten at
least) and doesn’t honor that case either. *Not* making the change will not
help us either…
So I’d say: let’s do it. If somebody objects (or proposes a change) then we can
handle that but at least we can claim that we try to give the users what we
preach, like writing natural language like code (e.g. “x + 1 month” which is
currently not possible).
That’s my view at least. Also: we’re changing so much stuff in Pharo anyway all
the time, I don’t think this would hurt.
That comment re 30 day months in financial is not totally correct.
A common reason for calculating days in a financial calculation is for interest
calculation and then you don't just need a number for the day difference but also for
the number of days in a year. When I did this I think I had to support many ways of
calculating the fraction of a year that was the difference between two dates
depending on the interest basis (ie the contract terms) , Wikipedia gives 11
<http://en.wikipedia.org/wiki/Day_count_convention>
So I think that adding a financial number of days into a basic date object does
not make sense as it will not be correct in many cases. The best way I have
seen is to pass a daycount basis strategy class into the calculation and that
strategy object does the calculation.
I like the idea of using strategies. Although some might argue that such a
change would unnecessarily bloat the code, strategies would give us the ability
to define our “standard” calculation in a central place while enabling everyone
to use their custom calculations.
It does not bloat the normal code - makes it smaller.You only need the
extra code if you need the extra financial calculations which most users
won't. Also it is not a unnecessary increase in code as if you neded
the calculations then you need the extra complexity
--
Mark
