diff --git a/src/lib/diff/gen-node.hpp b/src/lib/diff/gen-node.hpp index 41606287f..300770c72 100644 --- a/src/lib/diff/gen-node.hpp +++ b/src/lib/diff/gen-node.hpp @@ -52,6 +52,16 @@ ** addressable by-name and an (ordered) collection of elements treated ** as children within the scope of the given record. ** + ** ## The GenNode ID + ** + ** Each GenNode holds an ID tag, allowing to establish _identical_ and _distinct_ + ** elements within a scope. This ID is based on lib::idi::BareEntryID, thereby + ** providing a human readable symbolic part, and a hash value. By default, these + ** GenNode IDs are fabricated such as to hold a non-reproducible, random hash + ** value -- however, there are construction flavours allowing to pass in an + ** pre-existing distinct Entry-ID. + ** + ** ** # Requirements ** ** GenNode elements are to be used in the diff detection and implementation. @@ -66,7 +76,7 @@ ** typed context, either based on some kind of embedded type tag, or ** alternatively by visitation and matching ** - finally, the handling of changes prompts us to support installation - ** of a specifically typed change handling closure. + ** of a specifically typed _change handling closure_. ** ** ## monadic nature? ** @@ -223,6 +233,10 @@ namespace diff{ idi::getTypeHash()) { } + ID (string const& symbolicID, HashVal seed) + : idi::BareEntryID (symbolicID, seed) + { } + public: explicit ID (GenNode const& node) @@ -433,7 +447,15 @@ namespace diff{ } }; - + template + static GenNode + forAttribute (string const& key, X&& payload) + { + return GenNode{ID(key, std::rand()) // NOTE: random hash seed + ,DataCap(forward (payload))}; + } + + protected: /** @internal for dedicated builder subclasses */ GenNode (ID&& id, DataCap&& d) @@ -845,7 +867,7 @@ namespace diff{ inline GenNode Rec::buildAttribute (string const& key, X&& payload) { - return GenNode(key, std::forward(payload)); + return GenNode::forAttribute (key, forward(payload)); } diff --git a/src/lib/diff/record.hpp b/src/lib/diff/record.hpp index 0e2f8ce03..35e21e3bb 100644 --- a/src/lib/diff/record.hpp +++ b/src/lib/diff/record.hpp @@ -25,17 +25,22 @@ ** Special collection to represent object-like data. ** To be used in a context where introspection, open, extensible definitions ** and loose coupling of data representation matters. Typically, structures - ** defined in terms of Record elements are linked to the actual \em core + ** defined in terms of Record elements are linked to the _actual core_ ** representation of the same entities relying on [diff messages](\ref diff-language.hpp). ** Record is one of the supported flavours within the DataCap of GenNode elements, ** which in turn serve as the standard handle to refer to other elements, entities, ** attributes or references within the "backbone" of the Lumiera GUI. ** + ** A Record holds + ** - (optionally) a type-ID string + ** - a collection of _named attributes_ (key-value data) + ** - a list of _enclosed children_ (contents within the "scope" of this Record) + ** ** ## design decisions ** The Record type is shaped from its intended use: It serves to symbolically represent - ** _objects_ in the "external tree description". Here, "objects" means objects _for real_, - ** i.e. with types, fields and an enclosed scope. But \em external means that we do not work - ** on these objects right here, we only represent them, for later referral, _symbolically_. + ** *objects* in the "external tree description". Here, "objects" means objects _for real_, + ** i.e. with types, fields and an enclosed scope. Yet the term *external* means that we do not + ** work on these objects right here, we only represent them, for later referral, _symbolically_. ** ** \par rationale ** The underlying theme and motivation of this design is negative: we do not want diff --git a/wiki/thinkPad.ichthyo.mm b/wiki/thinkPad.ichthyo.mm index 4505370ec..7ce8628d3 100644 --- a/wiki/thinkPad.ichthyo.mm +++ b/wiki/thinkPad.ichthyo.mm @@ -6671,11 +6671,11 @@ - + - + @@ -6703,7 +6703,9 @@ - + + + @@ -20098,7 +20100,7 @@ - + @@ -20979,6 +20981,10 @@ + + + + @@ -21033,6 +21039,128 @@ + + + + + + + + + + + + + + + + + + + + + + + + + +

+ weil wir einen Mechanismus haben, die <cnt>-Dekoration pro Typ global hochzuzählen (treadsafe) +

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

+ Problem: key nur innerhalb des Objektes eindeutig +

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

+ ...denn dann müßte das Attribut +

+

+ von dem Container (GenNode) wissen, der es zwei Ebenen höher enthält und umschließt +

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

+ ...es kommt (vielleicht) überhaupt nicht darauf an, +

+

+ daß der Hash einer Attribut-ID reproduzierbar ist (auf Basis der symbilschen ID). +

+

+ Der Hash kann genausogut eine Zufallszahl sein +

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

+ ...nämlich diejenigen, die selber Modell-Elemente sind. +

+

+ Und genau diese speziellen Objekt-Attribute sind der Anlaß, +

+

+ sich über dieses Problem Gedanken zu machen +

+ + + + + + + + + @@ -21253,7 +21381,7 @@ - + @@ -21414,7 +21542,7 @@ - + @@ -21528,6 +21656,22 @@ + + + + + + +

+ Identität == Bus-ID +

+ + + + + + + @@ -21615,7 +21759,7 @@ - + @@ -39273,7 +39417,7 @@ - + @@ -39304,6 +39448,12 @@ + + + + + + @@ -39319,7 +39469,7 @@ - +