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
The base TransferAllowance class isn't really useful in any real-world system where there are differing transfer allowances per route/route type, because it only counts the number of transfer remaining, not what those transfers are to. I propose making it an interface that just has a boolean method atLeastAsGoodForAllFutureRedemptions, and let every individual transfer allowance handle its state internally. This would avoid confusion when new fare calculators are implemented; I know of at least two cases where this confusion has caused an issue - in the Boston calculator, where we were incorrectly cloning TransferAllowances and losing all Boston-specific information, and in the r5r fare calculator where the targets of the transfers were not being correctly tracked.
The text was updated successfully, but these errors were encountered:
The base TransferAllowance class isn't really useful in any real-world system where there are differing transfer allowances per route/route type, because it only counts the number of transfer remaining, not what those transfers are to. I propose making it an interface that just has a boolean method
atLeastAsGoodForAllFutureRedemptions
, and let every individual transfer allowance handle its state internally. This would avoid confusion when new fare calculators are implemented; I know of at least two cases where this confusion has caused an issue - in the Boston calculator, where we were incorrectly cloning TransferAllowances and losing all Boston-specific information, and in the r5r fare calculator where the targets of the transfers were not being correctly tracked.The text was updated successfully, but these errors were encountered: