I�ve taken a quick look at the implementation. It�s not strategy based but it would be easy enough for a user to add extensions (e.g. #fiscalYear) that have the same effect.
Apart from that, I think it would make more sense to inlclude the work that is being done for Squeak (including GenericMonth etc.) instead of using a similar but incompatible solution, which only addresses the problem of year duration anyway. There�s also the issue with the change of the �seconds� variable to use floats instead on integers.
Since issue 13229 isn�t my issue anyway and Carlo doesn�t seem to be active anymore I vote for closing the issue and for possibly adopting the Squeak implementation in the future.
I will cose the issue now, if somebody objects, feel free to reopen it.
Cheers,
Max
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