On 23/09/2014 08:48, Max Leske wrote:
On 19.09.2014, at 19:14, Mark Bestley <st@bestley.co.uk> 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