Refactor View classes:

The View hierarchy of classes is reorganized to include new
classes with member functions moved and renamed, to solve
defects in the original design:

OpenView accumulates raw state and tx changes and
can be applied to the base. ApplyView accumulates changes
for a single transaction, including metadata, and can be
applied to an OpenView. The Sandbox allows changes with
the option to apply or throw them out. The PaymentSandbox
provides a sandbox with account credit deferral.

Call sites are changed to use the class appropriate for
the task.
This commit is contained in:
Vinnie Falco
2015-07-04 10:55:07 -07:00
parent f3b172b0c9
commit 367c3a5bfc
116 changed files with 4392 additions and 3565 deletions

View File

@@ -327,7 +327,7 @@ Payment::doApply ()
{
path::RippleCalc::Output rc;
{
PaymentView pv (view(), view().flags());
PaymentSandbox pv(&view());
rc = path::RippleCalc::rippleCalculate (
pv,
maxSourceAmount,
@@ -339,7 +339,7 @@ Payment::doApply ()
// VFALCO NOTE We might not need to apply, depending
// on the TER. But always applying *should*
// be safe.
pv.apply(view());
pv.apply(ctx_.rawView());
}
// TODO: is this right? If the amount is the correct amount, was
@@ -351,7 +351,7 @@ Payment::doApply ()
mTxn.getFieldAmount (sfDeliverMin))
rc.setResult (tecPATH_PARTIAL);
else
ctx_.deliverAmount (rc.actualAmountOut);
ctx_.deliver (rc.actualAmountOut);
}
terResult = rc.result ();