[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi-commits] [lmi] master 5f5f3b5 01/16: Move a large comment block out
From: |
Greg Chicares |
Subject: |
[lmi-commits] [lmi] master 5f5f3b5 01/16: Move a large comment block outside a function definition |
Date: |
Sat, 11 Apr 2020 20:36:02 -0400 (EDT) |
branch: master
commit 5f5f3b5179f2be24819998a8cf6e9fbc09ab7680
Author: Gregory W. Chicares <address@hidden>
Commit: Gregory W. Chicares <address@hidden>
Move a large comment block outside a function definition
---
ledger_invariant.cpp | 51 +++++++++++++++++++++++++--------------------------
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/ledger_invariant.cpp b/ledger_invariant.cpp
index 658cd7d..983789b 100644
--- a/ledger_invariant.cpp
+++ b/ledger_invariant.cpp
@@ -488,7 +488,31 @@ void LedgerInvariant::Init()
FullyInitialized = false;
}
-//============================================================================
+// Notes on effective date.
+//
+// Should different cells in a census have different effective dates?
+// Should there be any consistency requirements at all?
+//
+// Pro: A census is just a collection of individuals. We could consider
+// adding the ability to append any individual (.ill) to any census (.cns).
+// That might be handy for putting together a regression test deck. Most
+// important, suppose a client bought one product for a number of employees
+// a few years ago, and is now adding new employees under a successor product;
+// don't we want to give them a combined composite if they ask?
+//
+// Con: Our task is simpler if we enforce strict consistency requirements.
+// There's less to think of, so the program will probably have fewer bugs;
+// although if overly strict requirements prevent the user from doing what
+// they want in some cases, that's a defect. I believe that vendor systems
+// generally have very strict consistency requirements.
+//
+// As to effective date in particular, I'm not sure what this item will
+// actually mean when we do reproposals. If it's plan inception date, then
+// it should be allowed to vary. If it's "as-of date" then I can't see a
+// reason to let it vary. Maybe these are different needs requiring separate
+// input items. What would we do with a plan established thirty years ago
+// that includes an individual who's already past the maturity date?
+
LedgerInvariant& LedgerInvariant::PlusEq(LedgerInvariant const& a_Addend)
{
LedgerBase::PlusEq(a_Addend, a_Addend.InforceLives);
@@ -530,31 +554,6 @@ LedgerInvariant& LedgerInvariant::PlusEq(LedgerInvariant
const& a_Addend)
// UWClass = a_Addend.Class;
// SubstandardTable
-// Should different cells in a census have different effective dates?
-// Should there be any consistency requirements at all?
-//
-// Pro: A census is just a collection of individuals. We could consider
-// adding the ability to append any individual (.ill) to any census (.cns).
-// That might be handy for putting together a regression test deck. Most
-// important, suppose a client bought one product for a number of employees
-// a few years ago, and is now adding new employees under a successor product;
-// don't we want to give them a combined composite if they ask?
-//
-// Con: Our task is simpler if we enforce strict consistency requirements.
-// There's less to think of, so the program will probably have fewer bugs;
-// although if overly strict requirements prevent the user from doing what
-// they want in some cases, that's a defect. I believe that vendor systems
-// generally have very strict consistency requirements.
-//
-// As to effective date in particular, I'm not sure what this item will
-// actually mean when we do reproposals. If it's plan inception date, then
-// it should be allowed to vary. If it's "as-of date" then I can't see a
-// reason to let it vary. Maybe these are different needs requiring separate
-// input items. What would we do with a plan established thirty years ago
-// that includes an individual who's already past the maturity date?
-//
-// Anyway, those are my thoughts; what conclusion would you reach?
-
EffDate = a_Addend.EffDate;
EffDateJdn = a_Addend.EffDateJdn;
DateOfBirth = a_Addend.DateOfBirth;
- [lmi-commits] [lmi] master updated (dfb045a -> ed9a11d), Greg Chicares, 2020/04/11
- [lmi-commits] [lmi] master 5f5f3b5 01/16: Move a large comment block outside a function definition,
Greg Chicares <=
- [lmi-commits] [lmi] master d888936 06/16: Move a comment to a more appropriate place, Greg Chicares, 2020/04/11
- [lmi-commits] [lmi] master cbc0ec5 03/16: Sort string members together in declaration order, Greg Chicares, 2020/04/11
- [lmi-commits] [lmi] master f7689a2 08/16: Regularize whitespace, Greg Chicares, 2020/04/11
- [lmi-commits] [lmi] master 95c2f88 02/16: Declutter, Greg Chicares, 2020/04/11
- [lmi-commits] [lmi] master ce9d6b8 04/16: Change compositing for some string members, Greg Chicares, 2020/04/11
- [lmi-commits] [lmi] master df9c566 07/16: Sort nonscalable scalar members together in declaration order, Greg Chicares, 2020/04/11
- [lmi-commits] [lmi] master a7a9404 05/16: Simplify [348], Greg Chicares, 2020/04/11
- [lmi-commits] [lmi] master 359c74c 09/16: Treat 'InitErMode' the same as any other ledger string, Greg Chicares, 2020/04/11
- [lmi-commits] [lmi] master 255b816 15/16: Mark ledger members dubiously ignored in compositing, Greg Chicares, 2020/04/11
- [lmi-commits] [lmi] master ed9a11d 16/16: Address ledger members formerly ignored in compositing, Greg Chicares, 2020/04/11