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. > > > > -- > Mark > >
