diff --git a/src/lib/time/mutation.hpp b/src/lib/time/mutation.hpp index 0d5810b5a..81b57c454 100644 --- a/src/lib/time/mutation.hpp +++ b/src/lib/time/mutation.hpp @@ -47,8 +47,8 @@ ** the message into the target object's own time grid. ** ** @note this header is defined such as to be used with or without including the time quantisation - ** facility, which is a more heavyweight regarding code size and compilation times. For this - ** toggle to work, the header \c timequant.hpp needs to be included \em prior to \c mutation.hpp + ** facility, which is a more heavyweight inclusion regarding code size and compilation times. For + ** this toggle to work, the header `timequant.hpp` needs to be included \em prior to `mutation.hpp` ** Obviously, you can't define any mutation involving quantised (grid aligned) values without this. ** @warning when defining more fancy kinds of concrete mutations using the technique with ** the EncapsulatedMutation to hide the implementation, then please be sure to understand diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 022e8e6e3..68a47fc70 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -8340,7 +8340,7 @@ attached to a clip, or the mixture of clips, effects and labels found within a [ You should note that this entire design is recursive: only after understanding the part, where, for handling a sub-structure, a nested mutator is fabricated and placed into a given buffer, it becomes clear to what effect we're creating a customised mutator: we always need some (relative) parent scope, which happens to know more about the actual data to be treated with a TreeMutator. This scope assists with creating a suitable binding. Obviously, from within that binding, it is known what the sub-structures and children of that local data are all about and what semantics to give to the fundamental operations. -
+
The TreeMutator is an intermediary to translate a generic structure pattern into heterogeneous local invocation sequences.
 
 !Motivation
@@ -8456,6 +8456,34 @@ Since our goal is to represent changes to structured objects in the form of a di
 * attributes may be reordered
 * attributes may be added and deleted
 -- none of which has any tangible meaning for a regular (language) object. To the contrary, our ExternalTreeDescription was built specifically to support diff language and diff messages, and thus has the ability to represent those changes. So, in theory, a given diff, when applied both to a GenNode and via TreeMutator to a native data structure, might lead to states not semantically equivalent. We can not reliably protect ourselves against that possibility, but, on the other hand, it is not clear if such is an actual threat.
+
+''A possible path to reconcile'' these inner contradictions is to support the mutation primitives ''as far as is sensible''.
+Through analysis of the semantics, we could distinguish several flavours of "attributes", especially...
+;object fields
+:mandatory elements enforced by class definition, where values need to be supplied at construction time
+;defaultable object fields
+:regular object fields proper, where some construction logic is able to fill in defaults. After construction, they are indistinguishable from mandatory object fields
+;optional properties
+:elements rooted in the class definition, yet not necessarily given. The object is able to //detect their absence//, and may fill in a default or ignore missing properties
+;attribute map
+:an ordered collection of key-value associations, which can be enumerated, searched and extended
+Thus we //could define a sensible handling for each of those cases, and deal with combinations// -- but --
+it seems more adequate to limit ourselves just to object fields and to include the defaultable object fields through implementation leeway. Because, in the end we really do need object fields, and anything beyond is just a representation of special behaviour and can be kept out of the diff system altogether. Through diff messages, we want to express structured changes, not metadata, nor closures, nor strategies, nor prototypes. And the attribute map is really something different than an object, and should be implemented separately, when it comes to applying diff messages to GenNode elements; the latter are able to //emulate// or //represent// objects, but actually are rather key-value associations arranged in and nested scopes.
+
+!!!mapping rules to handle object fields
+So we basically ''disallow'' anything related to ''order'', ''re-ordering'' and ''deletion'' of object fields.
+* when an object requires field values at construction time, this requirement has to be satisfied when inserting the object. The {{{ins}}} message must hold a complete value description in this case
+* beyond that, fields can //only// be either assigned, or opened for nested mutation.
+* for sake of consistency with the handling of a GenNode based [[ETD|ExternalTreeDescription]], we translate an {{{ins}}} message into an auto-accept followed by an assignment. In fact, any //defaultable object field,// when specified for the first time, //should// be given as {{{ins}}} message, because otherwise we would not be able to apply the same diff sequence to an equivalent GenNode representation of the same logical structure.
+Consequently, we're left with only a very limited subset of diff expression applicable to an »object field onion layer«
+* either a {{{pick}}} for every known field, possibly (optionally) followed by a {{{set}}} message with a new value
+* or an {{{after END}}}, followed (optionally) by an arbitrary sequence of {{{set}}} messages.
+To create a ''binding'' for any object field, we need
+* a ''name'' for matching keys
+* either a ''setter'' (lambda) or a ''mutator builder'' (lambda)
+We have a distinct typing for each individual attribute, but this typing remains implicit: the lambda has to know what value to extract from the GenNode payload within the accepted diff message
+
+
diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 800511fca..ba2439d94 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -45,8 +45,7 @@ heißt: Element registriert sich am UI-Bus

- - + @@ -58,8 +57,7 @@ heißt: Element deregistriert sich am UI-Bus

- - + @@ -73,8 +71,7 @@ ...ist immer ein tangible

- - + @@ -134,8 +131,7 @@ dafür genügt der normale Reset

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

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

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

- - + @@ -223,8 +216,7 @@ was haben alle UI-Elemente wirklich gemeinsam?

- - + @@ -242,8 +234,7 @@ oder handelt es sich nur um ein Implementierungsdetail der UI-Bus-Anbindung?

- - + @@ -331,8 +322,7 @@ Dann mußte das allerdigns jeweils für alle Elemente sinnvoll sein

- - + @@ -345,8 +335,7 @@ und der muß vom konkreten Widget implementiert werden

- - + @@ -508,8 +497,7 @@ Und ich muß das in einem Test zumindest emulieren können!

- - + @@ -549,8 +537,7 @@ - - + @@ -603,8 +590,7 @@ ist jedoch schon prototypisch implementiert

- - + @@ -983,8 +969,7 @@ (impl-ops)

- - + @@ -1049,8 +1034,7 @@ of this specific onion layer to accept forward until meeting this element.

- - + @@ -1079,8 +1063,7 @@ will check the bool return value and throw an exception in that case

- - + @@ -1789,8 +1772,7 @@ durch den das Problem mit der "absrakten, opaquen" Position entschärft wird

- - + @@ -1820,8 +1802,7 @@ - - + @@ -1845,8 +1826,7 @@  -- das gibt einen wichtigen Hinweis --

- - + @@ -1861,8 +1841,7 @@ also einen double-dispatch haben

- - + @@ -1886,8 +1865,7 @@ das Diff-System noch einmal reimplementieren, dann mit einem vorgegebenen Diff-Typ

- - + @@ -1934,8 +1912,7 @@ (will sagen, es ist nicht sofort offensichtlich, daß wir jeweils einen Interpreter generieren)

- - + @@ -2023,8 +2000,7 @@ und protokolliert somit "nebenbei" was an Anforderungen an ihm vorbeigeht

- - + @@ -2272,8 +2248,7 @@ für spezifische Arten von Bindings

- - + @@ -2315,8 +2290,7 @@ denn sonst würde er es für darunter liegende Layer verschatten.

- - + @@ -2358,7 +2332,7 @@ - + @@ -2770,8 +2744,7 @@ dann müssen Attribute irgendwie sinnvoll integriert sein

- - + @@ -2791,8 +2764,7 @@ ⟹ immer in der Klasse verankert

- - + @@ -2805,8 +2777,7 @@ ⟹ es geht eigentlich nur um den Wert des Attributes

- - + @@ -2824,8 +2795,7 @@ manche Felder sind optional

- - + @@ -2870,13 +2840,27 @@ wie ETD ein Objekt repäsentiert

- - + - + + + + + + +

+ "Anwendung" : meint das Anwenden eines Diffs auf ein Ziel-Objekt +

+

+ "nicht nutzen" : meint ignorieren und verwerfen der Information +

+ + + + @@ -2911,8 +2895,7 @@ zwingend die gleiche Reihenfolge erfordert!

- - + @@ -2936,8 +2919,7 @@ der sich letztlich nicht auf das Zielobjekt aufspielen läßt

- - + @@ -2950,8 +2932,7 @@ abweisen, was das Kriterium sicher verletzt

- - + @@ -2973,8 +2954,7 @@ default : es gibt einen ausgezeichneten Standardwert

- - + @@ -2990,8 +2970,7 @@ nicht nur eine leere Record-Hülle, die nachfolgend populiert werden kann (aber nicht muß)

- - + @@ -3010,8 +2989,7 @@ Ab dem Punkt verhält es sich aber wie ein normales (mandatory) Feld

- - + @@ -3023,8 +3001,7 @@ das Objekt selber kann erkennen, ob das Feld sich im "default-Zustand" befindet

- - + @@ -3055,8 +3032,7 @@ ohne Prüfen ist emptySrc nicht implementierbar

- - + @@ -3075,8 +3051,7 @@ alsauch der Check, daß überhaupt noch Quellelemente anstehen

- - + @@ -3088,8 +3063,7 @@ d.h., man kann nur global auf Prüfung verzichten 

- - + @@ -3101,8 +3075,7 @@ und da habe ich mich bereits dagegen entschieden

- - + @@ -3118,8 +3091,7 @@ Feld unterstützt default-Wert

- - + @@ -3142,8 +3114,7 @@ Primitiven

- - + @@ -3151,7 +3122,9 @@ - + + + @@ -3159,7 +3132,7 @@ - + @@ -3178,6 +3151,36 @@ + + + + + + +

+ Einschränkung: accept_until END +

+ + + + + + + + +

+ ...nämlich indem alle Attribute als "berührt" und akzeptiert markiert werden. +

+

+ Somit könnten sofort Zuweisungen als Nächstes passieren +

+ + + + + + + @@ -3204,8 +3207,7 @@ analog wie assignElm

- - + @@ -3232,8 +3234,7 @@ Operationen

- - + @@ -3260,8 +3261,38 @@ - + + + + + + + + + + +

+ sieht nach Ober-engineering aus, +

+

+ zumal das erhebliche Statefulness bewirkt +

+ + + + + + + + + + + + + + + @@ -3278,9 +3309,25 @@ unterstelle Ziel als konstruierbar aus Payload

+ + + + + + + + + +

+ da effektiv bereits der Setter diese Funktionalität enthalten kann und muß, +

+

+ denn der Setter nimmt eine GenNode +

+ - + @@ -3290,7 +3337,7 @@ - + @@ -3300,6 +3347,202 @@ + + + + + + + + + + +

+ injectNew tolerieren +

+ + + + + + + + + + +

+ ....man könnte genausogut auch beim ersten Mal zuweisen +

+ + + + + + + + + + +

+ denn die Diff-Anwendung auf GenNode unterstützt Zuweisung +

+

+ ausschließlich bei schon existierenden Elementen. Demnach muß dort auch jedes Attribut +

+
    +
  • + entweder schon mit dem Konstruktor mit gegeben worden sein +
    • +
  • + oder vorher einmal explizit eingefügt +
    • +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +

+ ...denn wir vermeiden dadurch Komplexität. +

+

+ Der gesendete Diff muß einfach passen! +

+

+ Genau deshalb haben wir auch in GenNode verschiedene Varianten des gleichen Grundtyps, +

+

+ damit wir nicht in die ganzen Ungewissheiten der widening conversions laufen! +

+ + + + + + + + + + + + + + + + + + + + + + + +

+ d.h. der Attributwert hat Wertsemantik und wird einfach zugewiesen +

+ + + + + + + + + + +

+ ...d.h. der Attributwert ist ein Objekt und damit ein nested Scope +

+ + + + + + + + + + + + + +

+ Problem: immutable values +

+ + + + + + + + + + + + + + + + + + + + + + + + + +

+ das alles passiert dann im Lambda +

+ + + + + + + + + @@ -3309,7 +3552,14 @@ - + + + + + + + + @@ -3333,8 +3583,7 @@ Problem: partielle Ordnung

- - + @@ -3364,8 +3613,7 @@ In jedem Fall gerät dadurch die relative Verzahnung der Elemente untereinander aus dem Takt

- - + @@ -3393,8 +3641,7 @@ und diese Elemente müssen geschlossen hintereinander in der Reihenfolge liegen

- - + @@ -3414,8 +3661,7 @@ ...denn es ist sehr verwirrend, welche Signatur denn nun die Lambdas haben müssen

- - + @@ -3428,8 +3674,7 @@ ...denn es kann keinen Default-Matcher geben....

- - + @@ -3449,8 +3694,7 @@ daß der Client hier eigentlich ein Protokoll implementieren muß.

- - + @@ -3918,8 +4162,7 @@ Implementierung der real-world-Variante fehlt!

- - +