From c0ee98d73d189c03cd79491e2b982eb88f8ab6c4 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Wed, 17 Feb 2016 01:38:04 +0100 Subject: [PATCH] planning: find out what the next steps would be like ...we want to attack the structural mutaion, finally --- src/lib/diff/tree-diff-application.hpp | 18 ++-- wiki/renderengine.html | 8 +- wiki/thinkPad.ichthyo.mm | 141 ++++++++++++++++++++----- 3 files changed, 130 insertions(+), 37 deletions(-) diff --git a/src/lib/diff/tree-diff-application.hpp b/src/lib/diff/tree-diff-application.hpp index a9ea44dcb..7105a9757 100644 --- a/src/lib/diff/tree-diff-application.hpp +++ b/src/lib/diff/tree-diff-application.hpp @@ -40,7 +40,7 @@ ** a switch from scope to scope, which adds a lot of complexity. So the list diff ** application strategy can be seen as blueprint and demonstration of principles. ** - ** Another point in question is weather to treat the diff application as + ** Another point in question is whether to treat the diff application as ** manipulating a target data structure, or rather building a reshaped copy. ** The fact that GenNode and Record are designed as immutable values seems to favour ** the latter, yet the very reason to engage into building this diff framework was @@ -280,7 +280,7 @@ namespace diff{ /* == Implementation of the list diff application primitives == */ - void + virtual void ins (GenNode const& n) override { if (n.isNamed()) @@ -296,14 +296,14 @@ namespace diff{ } } - void + virtual void del (GenNode const& n) override { __expect_in_target(n, "remove"); ++src(); } - void + virtual void pick (GenNode const& n) override { __expect_in_target(n, "pick"); @@ -311,14 +311,14 @@ namespace diff{ ++src(); } - void + virtual void skip (GenNode const& n) override { __expect_further_elements (n); ++src(); } // assume the actual content has been moved away by a previous find() - void + virtual void find (GenNode const& n) override { __expect_further_elements (n); @@ -334,7 +334,7 @@ namespace diff{ /** cue to a position behind the named node, * thereby picking (accepting) all traversed elements * into the reshaped new data structure as-is */ - void + virtual void after (GenNode const& n) override { if (n.matches(Ref::ATTRIBS)) @@ -364,7 +364,7 @@ namespace diff{ } /** open nested scope to apply diff to child object */ - void + virtual void mut (GenNode const& n) override { GenNode const& child = find_child (n.idi); @@ -376,7 +376,7 @@ namespace diff{ } /** finish and leave child object scope, return to parent */ - void + virtual void emu (GenNode const& n) override { TRACE (diff, "tree-diff: LEAVE scope %s", cStr(alteredRec())); diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 9fab5e233..0663b25fe 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -4892,7 +4892,7 @@ The backbone of the Lumiera UI is arranged such as to produce a data feed with s Run as part of the UiCoreServices, it is attached to the UI-Bus and listens to all ''state mark messages'' to distil the notion of relevant current state. On a basic level, the task is to group and store those messages in a way as to overwrite previous messages with new updates on the level of individual properties. Beyond that, there is the sensitivity to context, presentation perspective and work site, which means to impose an additional structure on this basic ''state snapshot'', to extract and replicate structured sets of state information. -
+
Open issues, Things to be worked out, Problems still to be solved... 
 
 !!Parameter Handling
@@ -4928,10 +4928,10 @@ We need to work out guidelines for dealing with operations going on simultaneous
 * all EditingOperations are not threadsafe intentionally, because they are [[scheduled|ProcLayerScheduler]]
 
 !!the perils of data representation
-In software development, there is a natural inclination to cast "reality" into data, the structure of which has to be nailed down first. Then, everyone might "access reality" and work on it. Such sounds natural, self-evident and sound, yet to the same extent this approach is fundamentally flawed. It is known to work well for small, "handsome" projects, where you clearly know up-front what you're up to: namely to get away, after being paid, before anyone realises the fact you've built something that looks nice but does not fit.
-So the challenge of any major undertaking in software construction is //not to build a model.// Rather, we want to arrive at something that can be made to fit. Over and over again.
+In software development, there is a natural inclination to cast "reality" into data, the structure of which has to be nailed down first. Then, everyone might "access reality" and work on it. Doing so might sounds rational, natural, even self-evident and sound, yet as compelling as it might be, this approach is fundamentally flawed. It is known to work well only for small, "handsome" projects, where you clearly know up-front what you're up to: namely to get away, after being paid, before anyone realises the fact you've built something that looks nice but does not fit.
+So the challenge of any major undertaking in software construction is //not to build an universal model.// Rather, we want to arrive at something that can be made to fit. Over and over again.
 
-More specifically, we start building something, and while under way, our understanding sharpens, and we learn that actually we want something different. But we don't want just something arbitrary. There is a constant core in what we're headed at, and we need the ability to //settle matters.// We need a backbone to work against, to support us with its firmness, but also to offer joints and links, to be bent and remoulded without breakage. The distinctive idea to make such possible is the principle of subsidiarity. The links and joints between such autonomous centres can be shaped to be in fact an exchange, based on common understanding of the //specific matters to deal with,// at that given joint.
+More specifically, we start building something, and while under way, our understanding sharpens, and we learn that actually we want something entirely different. Yet still we know what we need and  we don't want just something arbitrary. There is a constant core in what we're headed at, and we need the ability to //settle matters.// We need a backbone to work against, a skeleton to support us with its firmness, while also offering joints and links, to be bent and remoulded without breakage. The distinctive idea to make such possible is the principle of subsidiarity. The links and joints between autonomous centres can be shaped to be in fact an exchange, a handover based on common understanding of the //specific matters to deal with,// at that given joint.
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index f2659e943..4bead9d6b 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -131,8 +131,7 @@ dafür genügt der normale Reset

- - + @@ -145,8 +144,7 @@ mark "clearMsg"

- - + @@ -158,8 +156,7 @@ mark "clearErr"

- - + @@ -171,8 +168,7 @@ mark "reset"

- - + @@ -298,8 +294,7 @@ Für die UI-Programmierung muß man Spaghetticode akzeptieren.

- - + @@ -391,8 +386,7 @@ support ist optional

- - + @@ -434,8 +428,7 @@ sollte logischerweise der PresentationStateManager leer sein

- - + @@ -457,13 +450,117 @@ und eine state mark "reset" zurückschicken...

- - + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ muß DiffApplicationStrategy +

+

+ noch einmal implementieren +

+ + + + + + + + +

+ das mag überraschen -- +

+

+ ist aber im Sinne des Erfinders +

+
    +
  • + DiffApplicationStrategy war von Anfang an als technisches Binding konzipiert +
    • +
  • + es ist besser, die gleiche Semantik der Sprache X-mal herunterzucoden +
    • +
  • + cleverer Code-re-Use zahlt sich i.d.R. nicht aus +
    • +
+ + + + + + + + + + +

+ dies setzt volle Implementierung +

+

+ des Tree-Mutators voraus +

+ + + + + + + + +

+ der schwierigste Teil, das Mutieren von Attributen, +

+

+ ist jedoch schon prototypisch implementiert +

+ + + + + + + + + + + + + + + + + + @@ -899,8 +996,7 @@ Implementierung der real-world-Variante fehlt!

- - + @@ -1050,8 +1146,7 @@ empfängt alle state mark notificatons

- - + @@ -1076,8 +1171,7 @@ nach Perspektive

- - + @@ -1089,8 +1183,7 @@ nach work site

- - +