You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
well if you want some help more than willing to pitch in, just need to agree on how implement my thought is to rename the function newMonthlyDebtAmortization to newMonthlySimpleDebtAmortization and newMonthlyComplexDebtAmortization... simple being the current method and complex being alternative interest calculation methods. If we are going to move forward this, I would also like to support for loans with ballons
The initial thought as to how to handle this was to have a convention defined (and selected) in the global settings file, with the possibility to override it through optional arguments of concerned methods (so that the setting doesn't have to be changed in case there's a need to work with multiple conventions within a single application). So basically a concept compatible (if not the exact same thing 😃) with what you suggest.
It's a good idea to distinguish the "simple" and "complex" methods in their name to be obvious at a glance but here I'd rather tackle it with something like an optional method argument, because otherwise it would make already long and convoluted method names even more complex (this is a problem with many methods and class members, though curtailing the names would detract from clarity).
Support for loans with balloon payments can be added, noting it down. 👍
I think an optional method argument is a good solution, then it is possible to implement different methods of amortization the future:
newMonthlyDebtAmortization(40000, 60, 0.12, LINEAR) // straight linear amortization
newMonthlyDebtAmortization(40000, 60, 0.12, ANNUITY) // current implementation
newMonthlyDebtAmortization(40000, 60, 0.12, BULLET) // all at once, paid on the last period
etc...
I agree with optional argument. Below are all the different interest calculation types I think we should include. Last few are rare. If you know of any others please add to the list.
Yes, I think we should include at least the most used ones, but of course the more the better. I've found this list at the webpage of SAP company. Wikipedia also has a nice article on this that I think can be used as a starting point.
And as for the #4, @cjnqt demonstrated nicely the thought behind the optional argument (which can be represented, for example, by an enum, like it already is with some of the identifiers – e.g. the "payment" or "value" type of an annuity, etc.).
Activity
uruba commentedon Mar 11, 2016
Hello, yes, this has certainly been on the radar for some time now. I however cannot promise when I will finally get around to implementing it.
strikerz5 commentedon Mar 11, 2016
well if you want some help more than willing to pitch in, just need to agree on how implement my thought is to rename the function newMonthlyDebtAmortization to newMonthlySimpleDebtAmortization and newMonthlyComplexDebtAmortization... simple being the current method and complex being alternative interest calculation methods. If we are going to move forward this, I would also like to support for loans with ballons
uruba commentedon Mar 12, 2016
The initial thought as to how to handle this was to have a convention defined (and selected) in the global settings file, with the possibility to override it through optional arguments of concerned methods (so that the setting doesn't have to be changed in case there's a need to work with multiple conventions within a single application). So basically a concept compatible (if not the exact same thing 😃) with what you suggest.
It's a good idea to distinguish the "simple" and "complex" methods in their name to be obvious at a glance but here I'd rather tackle it with something like an optional method argument, because otherwise it would make already long and convoluted method names even more complex (this is a problem with many methods and class members, though curtailing the names would detract from clarity).
Support for loans with balloon payments can be added, noting it down. 👍
cjnqt commentedon Mar 16, 2016
Great project!
I think an optional method argument is a good solution, then it is possible to implement different methods of amortization the future:
strikerz5 commentedon Mar 21, 2016
I agree with optional argument. Below are all the different interest calculation types I think we should include. Last few are rare. If you know of any others please add to the list.
30/360 - Most Common... default?
30/365
actual/360
actual/365
360/365
365/365
365/360
uruba commentedon Mar 22, 2016
Yes, I think we should include at least the most used ones, but of course the more the better. I've found this list at the webpage of SAP company. Wikipedia also has a nice article on this that I think can be used as a starting point.
And as for the #4, @cjnqt demonstrated nicely the thought behind the optional argument (which can be represented, for example, by an enum, like it already is with some of the identifiers – e.g. the "payment" or "value" type of an annuity, etc.).