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
I propose a new interface for policies objects. While working on ReLife, I found it very cumbersome to write method names like expected_total_cost or expected_equivalent_annual_cost. The situation worsens with asymptotic_* methods, as their names are excessively long and prone to typos. I believe it would be more efficient, intuitive, and less error-prone to adopt a more concise approach, such as
policy.expected_cost(timeline) # Implicitly calculates the total cost
policy.expected_eac(timeline) # More succinct, reducing potential for errors/typos
In this approach, total cost could be treated as the default computation, as it's commonly used. If other types of costs need to be calculated, their methods would explicitly reference those types in their names, making the purpose clearer.
For asymptotic cases, I propose integrating an optional argument to simplify the method names further:
In this case, the timeline parameter would become optional. If both timeline and asymptotic=True are provided, a warning such as "Unnecessary timeline provided. The timeline will be ignored when asymptotic=True is used." could be raised to inform the user of the redundant input.
The text was updated successfully, but these errors were encountered:
I propose a new interface for policies objects. While working on ReLife, I found it very cumbersome to write method names like
expected_total_cost
orexpected_equivalent_annual_cost
. The situation worsens withasymptotic_*
methods, as their names are excessively long and prone to typos. I believe it would be more efficient, intuitive, and less error-prone to adopt a more concise approach, such asIn this approach, total cost could be treated as the default computation, as it's commonly used. If other types of costs need to be calculated, their methods would explicitly reference those types in their names, making the purpose clearer.
For asymptotic cases, I propose integrating an optional argument to simplify the method names further:
In this case, the
timeline
parameter would become optional. If bothtimeline
andasymptotic=True
are provided, a warning such as "Unnecessary timeline provided. The timeline will be ignored whenasymptotic=True
is used." could be raised to inform the user of the redundant input.The text was updated successfully, but these errors were encountered: