Commit graph

13 commits

Author SHA1 Message Date
c94bbcbb15 extend storage arrangement to deal with nested child objects
It is difficult to reconcile our general architecture for the
linearised diff representation with the processing of recursive,
tree-like data structures. The natural and most clean way to
deal with trees is to use recursion, i.e. the processor stack.
But in our case, this means we'd have to peek into the next
token of the language and then forward the diff iterator
into a recursive call on the nested scope. Essentially, this
breaks the separation between receiving a token sequence and
interpretation for a concrete target data structure.

For this reason, it is preferrable to make the stack an
internal state of the concrete interpreter. The downside of
this approach is the quite confusing data storage management;
we try to make the role of the storage elements a bit more
clear through descriptive accessor functions.
2015-10-30 03:11:33 +01:00
e5ffcf224f implementation: list diff operations in tree-diff-applicator
implement the list handling primitives analogous to the
implementation of list-diff-applicator -- just again with
the additional twist to keep the attribute and child scopes
separated.
2015-10-29 04:14:18 +01:00
2882d78755 implementation: simplest case (insert element)
...so now the stage is set. We can reimplement
the handling of the list diff cases here in the context
of tree diff application. The additional twist of course
being the distinction between attribute and child scope
2015-10-24 03:15:35 +02:00
4356315021 diff-language interpreter: prefer to take payload by const&
each language token of our "linearised diff representation"
carries a payload data element, which typically is the piece
of data to be altered (added, mutated, etc).

Basically, these elements have value semantics and are
"sent over wire", and thus it seems natural when the
language interpreter functions accept that piece of payload
by-value. But since we're now sending GenNode elements as
parameter data in our diff, which typically are of the
size of 10 data elements (640 bit on a 64bit machine),
it seems more resonable to pass these argument elements
by const& through the interpreter function. This still
means we can (and will indeed) copy the mutated data
values when applying the diff, but we're able to
relay the data more efficiently to the point where
it's consumed.
2015-10-24 02:42:13 +02:00
aa46940daa indicate how RecordContentMutator will be used 2015-10-23 21:08:33 +02:00
e438a9fe51 chosing an implementation approach for tree-diff-application 2015-10-23 19:24:34 +02:00
c90e6a6f65 on second thought: yet a better solution
...is to let the diff applicator work *on* a Rec::Mutator
This is outright natural -- why is it that I needed 2 days
to come up with this solution?
2015-10-23 01:32:47 +02:00
eabeee3b7b decide on the implementation approach for tree diff application
this boils down to the two alternatives
 - manipulate the target data structure
 - build an altered copy

since our goal is to handle large tree structures efficiently,
the decision was cast in favour of data manipulation
2015-10-23 00:40:02 +02:00
90f31df8c0 stub the diff verb operations.
passes compilation again
2015-10-09 03:44:38 +02:00
2704b38da6 WIP rework demonstration diff to be valid type-wise
so basically it's time to explicate the way
our diff language will actually be written.

Similar to the list diff case, it's a linear sequence
of verb tokens, but in this case, the payload value
in each token is a GenNode. This is the very reason
why GenNode was conceived as value object with an
opaque DataCap payload
2015-10-09 03:03:27 +02:00
eaba418d15 WIP start definition with a basic tree diff example... 2015-10-02 18:47:44 +02:00
9707a8982c Diff Handling and Diff Application: framework and definitions
factored out of the concept test built last week.
2014-12-15 03:21:19 +01:00
658698407e use the successful concept test as starting point for a diff handling system
...basically move code from test to various headers
2014-12-15 01:27:03 +01:00