resolve some conflicts in the design of the "External Tree Representation"
for the purpose of working out the inner logic, I frequently use the help of a mindmap -- so why not commiting this alongside? For sure, it is preliminary and the worked out concepts will be cast in code and documented on the website. Yet the thought-process leading to these decisions might be of some interest, at least for myself.
This commit is contained in:
parent
bee4d11b34
commit
c70ad01ad3
2 changed files with 247 additions and 8 deletions
|
|
@ -1970,7 +1970,7 @@ It would thus be desirable to have a fixed-sized allocation, able to hold the pl
|
|||
!!!Storage
|
||||
Explicit placements are value objects and stored at the respective usage site, most notably the [[Segmentation]]. They are //not// attached to the placement index in the session, nor do they bear any referential or indexing semantics. The only dynamic side effect of an explicit placement is to keep the reference count of the corresponding MObject up and thus keep it alive and accessible.</pre>
|
||||
</div>
|
||||
<div title="ExternalTreeDescription" creator="Ichthyostega" modifier="Ichthyostega" created="201505081647" modified="201506041327" tags="Concepts Model design spec draft" changecount="21">
|
||||
<div title="ExternalTreeDescription" creator="Ichthyostega" modifier="Ichthyostega" created="201505081647" modified="201506121606" tags="Concepts Model design spec draft" changecount="27">
|
||||
<pre>//to symbolically represent hierarchically structured elements, without actually implementing them.//
|
||||
The purpose of this »external« description is to remove the need of a central data model to work against. We consider such a foundation data model as a good starting point, yet harmful for the evolution of any larger structure to be built. According to the subsidiarity principle, we prefer to turn the working data representation into a local concern. Which leaves us with the issue of collaboration. Any collaboration requires, as an underlying, some kind of common understanding. And any formalised, mechanical collaboration requires to represent that common point of attachment -- at least as symbolic representation. The ExternalTreeDescription is shaped to fulfil this need: //in theory,// the whole field could be represented, symbolically, as a network of hierarchically structured elements. Yet, //in practice,// all we need is to conceive the presence of such a representation, as a backdrop to work against. And we do so -- we work against that symbolic representation, by describing ''changes'' made to the structure and its elements. Thus, the description of changes, the ''diff language'', refers to and partially embodies such symbolically represented elements and relations.
|
||||
&rarr; TreeDiffFundamentals
|
||||
|
|
@ -1985,9 +1985,9 @@ For practical purposes, we have to introduce some distinctions and limitations.
|
|||
* to the contrary, a Record has an associated, symbolic type-ID, plus it can potentially be associated with and thus relate to further elements, with the relation originating at the Record.
|
||||
* and we distinguish two different kinds of relations possibly originating from a Record:
|
||||
** ''attributes'' are known by-name; they can be addressed through this name-ID as a key, while the value is again a generic node, possibly even another record.
|
||||
** ''children'' to the contrary can only be ennumerated; they are considered to be within (and form) the ''scope'' of the given Record (object).
|
||||
** ''children'' to the contrary can only be enumerated; they are considered to be within (and form) the ''scope'' of the given Record (object).
|
||||
|
||||
And there is a further limitation: Tthe domain of possible data is fixed, even hard wired. Implementation-wise, this turns the data within the generic node into a »Variant« (typesafe union). Basically, this opens two different ways to //access// the data within a given GenNode: either you know the type to expect beforehand (and the validity of this assumption is checked on each access; please recall, all of this is meant for symbolic representation, not for implementation of high performance computing). Or we offer the ability for //generic access// through a ''variant visitor'' (double dispatch). The latter includes the option not to handle all possible content types (making the variant visitor a //partial function// -- as in any non exhaustive pattern match).
|
||||
And there is a further limitation: The domain of possible data is fixed, even hard wired. Implementation-wise, this turns the data within the generic node into a »Variant« (typesafe union). Basically, this opens two different ways to //access// the data within a given GenNode: either you know the type to expect beforehand (and the validity of this assumption is checked on each access; please recall, all of this is meant for symbolic representation, not for implementation of high performance computing). Or we offer the ability for //generic access// through a ''variant visitor'' (double dispatch). The latter includes the option not to handle all possible content types (making the variant visitor a //partial function// -- as in any non exhaustive pattern match).
|
||||
|
||||
Basically, you can expect to encounter the following kinds of data
|
||||
*{{{int}}}, {{{int64_t}}}, {{{short}}}, {{{char}}}
|
||||
|
|
@ -2010,16 +2010,16 @@ Operationally, a modad can be constructed to wrap-up and embody a given element.
|
|||
Now, the interesting question is: //what does "join" mean?// --
|
||||
*will it drill down?
|
||||
*will it lift the contents of generated monads into the parent level, or attach them as new subtrees?
|
||||
*will the function get to see {{{Record}}} elements, or will it imediately see the "contents", the attributes or the children?
|
||||
*will the function get to see {{{Record}}} elements, or will it immediately see the "contents", the attributes or the children?
|
||||
|
||||
!!!names, identity and typing
|
||||
It was a design decision that the GenNode shall not embodiy a readable type field, just a type selector within the variant to hold the actual data elements.
|
||||
This decision more or less limits the usefulness of simple values as children to those cases, where all children are of uniform type, or where we agree to deal with all children through variant visitation solely. Of course, we can still use simple values as attributes, since those are known and addressed by name. And we can use filtereing by type to limit access to some children of type record, since every record does indeed embody a symbolic type name. It must be that way, since otherwise, records would be pretty much useless as representation for any object like entity.
|
||||
It was a design decision that the GenNode shall not embody a readable type field, just a type selector within the variant to hold the actual data elements.
|
||||
This decision more or less limits the usefulness of simple values as children to those cases, where all children are of uniform type, or where we agree to deal with all children through variant visitation solely. Of course, we can still use simple values as //attributes,// since those are known and addressed by name. And we can use filtering by type to limit access to some children of type {{{Record}}}, since every record does indeed embody a symbolic type name, an attribute named {{{"type"}}}. It must be that way, since otherwise, records would be pretty much useless as representation for any object like entity.
|
||||
|
||||
The discriminating ID of any GenNode can serve as a name, and indeed will be used as the name of an attribute within a record.
|
||||
Now, the interesting question is: what constitues the full identity? Is it the ~ID-string? does it also include some kind of type information, so that two children with the same name, but different types would be considered different? And, moreover, we could even go as far as to make the path part of the identity, so that two otherwise identical elements would be different, when located at different positions within the graph. But since we did not rule out cyclic graphs, the latter idea would necessitate the notion of an //optimal path// --
|
||||
Now, the interesting question is: what constitutes the full identity? Is it the ~ID-string? does it also include some kind of type information, so that two children with the same name, but different types would be considered different? And, moreover, we could even go as far as to make the path part of the identity, so that two otherwise identical elements would be different, when located at different positions within the graph. But since we did not rule out cyclic graphs, the latter idea would necessitate the notion of an //optimal path// --
|
||||
|
||||
A somewhat similar question is the ordering and uniqueness of children. While attributes -- due to the usage of the attribute node's ID as name-key -- are bound to be unique within a given Record, children within the scope of a record could be required to be unique too, making the scope a set. And, of course, children could be focribly ordered, or just retain the initial ordering, or even be completely unordered. On a second thought, it seems wise not to impose any guarantees in that regard, beyond the simple notion of retaining an initial sequence order, the way a »stable« sorting algorithm does. All these more specific ordering properties can be considered the concern of some specific kinds of objects -- which then just happen to "supply" a list of children for symbolic representation as they see fit.
|
||||
A somewhat similar question is the ordering and uniqueness of children. While attributes -- due to the usage of the attribute node's ID as name-key -- are bound to be unique within a given Record, children within the scope of a record could be required to be unique too, making the scope a set. And, of course, children could be forcibly ordered, or just retain the initial ordering, or even be completely unordered. On a second thought, it seems wise not to impose any guarantees in that regard, beyond the simple notion of retaining an initial sequence order, the way a »stable« sorting algorithm does. All these more specific ordering properties can be considered the concern of some specific kinds of objects -- which then just happen to "supply" a list of children for symbolic representation as they see fit.
|
||||
</pre>
|
||||
</div>
|
||||
<div title="Factories" modifier="Ichthyostega" created="200708100401" modified="201310132317" tags="def Concepts" changecount="6">
|
||||
|
|
|
|||
239
wiki/thinkPad.ichthyo.mm
Normal file
239
wiki/thinkPad.ichthyo.mm
Normal file
|
|
@ -0,0 +1,239 @@
|
|||
<map version="1.0.1">
|
||||
<!-- To view this file, download free mind mapping software FreeMind from http://freemind.sourceforge.net -->
|
||||
<node BACKGROUND_COLOR="#6666ff" CREATED="1434127882200" ID="ID_1452170048" MODIFIED="1434128038348" TEXT="Lumi">
|
||||
<font NAME="SansSerif" SIZE="18"/>
|
||||
<node CREATED="1434128046296" ID="ID_1900827283" MODIFIED="1434128053553" POSITION="right" TEXT="GUI">
|
||||
<node CREATED="1434128054470" ID="ID_1166611516" MODIFIED="1434128059666" TEXT="Workflow"/>
|
||||
<node CREATED="1434128059966" ID="ID_823283341" MODIFIED="1434128067529" TEXT="Connect">
|
||||
<node CREATED="1434128071126" ID="ID_1618124128" MODIFIED="1434128074137" TEXT="UI-Bus">
|
||||
<node CREATED="1434128297445" ID="ID_1971555917" MODIFIED="1434128300889" TEXT="Nachrichtenformat"/>
|
||||
<node CREATED="1434128301525" ID="ID_187622243" MODIFIED="1434128303993" TEXT="Parallelität"/>
|
||||
<node CREATED="1434128332277" ID="ID_33025591" MODIFIED="1434128337777" TEXT="Deregistrierung"/>
|
||||
<node CREATED="1434128310005" ID="ID_644247390" MODIFIED="1434128318561" TEXT="Knoten-ID"/>
|
||||
</node>
|
||||
<node CREATED="1434128074725" ID="ID_933994138" MODIFIED="1434128077625" TEXT="Diff-System">
|
||||
<node CREATED="1434128278990" ID="ID_106354755" MODIFIED="1434128283641" TEXT="Diff-Darstellung"/>
|
||||
<node CREATED="1434128267381" ID="ID_823706141" MODIFIED="1434128551925" TEXT="List-diff">
|
||||
<icon BUILTIN="go"/>
|
||||
</node>
|
||||
<node CREATED="1434128078638" ID="ID_1704749549" MODIFIED="1434128568744" TEXT="Tree-Diff">
|
||||
<icon BUILTIN="prepare"/>
|
||||
<node CREATED="1434128095838" ID="ID_419405890" MODIFIED="1434128561967" TEXT="Detector">
|
||||
<icon BUILTIN="stop"/>
|
||||
</node>
|
||||
<node CREATED="1434128092877" ID="ID_105246595" MODIFIED="1434128109517" TEXT="Applikator">
|
||||
<node CREATED="1434128115462" ID="ID_1299653797" MODIFIED="1434128119065" TEXT="Tree-Mutator"/>
|
||||
</node>
|
||||
<node CREATED="1434128083878" ID="ID_937754899" MODIFIED="1434128494612" TEXT="Format">
|
||||
<node CREATED="1434128153773" ID="ID_1289483934" MODIFIED="1434128577748" TEXT="Objekt-Repräs">
|
||||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1434128243334" ID="ID_1828331212" MODIFIED="1434128248667" TEXT="Typ-Darstellung"/>
|
||||
<node CREATED="1434128239517" ID="ID_1886740948" MODIFIED="1434128250041" TEXT="Mapping"/>
|
||||
<node CREATED="1434128170381" ID="ID_976705384" MODIFIED="1434128380059" TEXT="GenNode">
|
||||
<linktarget COLOR="#ff0033" DESTINATION="ID_976705384" ENDARROW="Default" ENDINCLINATION="2;9;" ID="Arrow_ID_1285375088" SOURCE="ID_553361956" STARTARROW="Default" STARTINCLINATION="26;-13;"/>
|
||||
<node CREATED="1434128174030" ID="ID_1395250463" MODIFIED="1434128176521" TEXT="Variant"/>
|
||||
<node CREATED="1434128217645" ID="ID_1790054544" MODIFIED="1434128220257" TEXT="Monade"/>
|
||||
<node CREATED="1434128176918" ID="ID_863330674" MODIFIED="1434128195333" TEXT="Record">
|
||||
<node CREATED="1434128198957" ID="ID_1224215957" MODIFIED="1434128203817" TEXT="Konstuktor"/>
|
||||
<node CREATED="1434128179406" ID="ID_1833179523" MODIFIED="1434129153311" TEXT="Referez">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node CREATED="1434129158157" ID="ID_1777328498" MODIFIED="1434129165457" TEXT="sicher dereferenzierbar">
|
||||
<node CREATED="1434205928410" ID="ID_733269570" MODIFIED="1434205947253" TEXT="entweder zwangsweise gebunden"/>
|
||||
<node CREATED="1434205947841" ID="ID_871233558" MODIFIED="1434205955964" TEXT="oder NULL-Zustand mit Exception"/>
|
||||
<node CREATED="1434205957177" ID="ID_499991180" MODIFIED="1434205968740" TEXT="inherente Unsicherheit einer Referenz"/>
|
||||
</node>
|
||||
<node CREATED="1434129167805" ID="ID_819452470" MODIFIED="1434129251779" TEXT="stand-in">
|
||||
<arrowlink COLOR="#00ff33" DESTINATION="ID_654762061" ENDARROW="Default" ENDINCLINATION="457;0;" ID="Arrow_ID_724106052" STARTARROW="Default" STARTINCLINATION="457;0;"/>
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1434129196709" ID="ID_1004519740" MODIFIED="1434150973939" TEXT="Subklasse von Rec">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
scheidet aus, wegen Wertsemantik
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<icon BUILTIN="button_cancel"/>
|
||||
</node>
|
||||
<node CREATED="1434129204149" ID="ID_1688475597" MODIFIED="1434129212537" TEXT="GenNode">
|
||||
<node CREATED="1434205661969" ID="ID_1484374626" MODIFIED="1434205705054">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
mit <i>speziellem </i>Ref-Typ
|
||||
</p>
|
||||
<p>
|
||||
<font size="1">-- im DataCap</font>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#ffcccc" COLOR="#990033" CREATED="1434205598709" ID="ID_235720343" MODIFIED="1434205652458" TEXT="stand-in heißt...">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1434205739609" ID="ID_1185983904" MODIFIED="1434205778045" TEXT="kann anstelle eines Objektes treten"/>
|
||||
<node CREATED="1434205834506" ID="ID_1477654683" MODIFIED="1434205859229" TEXT="transparent für den Aufrufer"/>
|
||||
<node CREATED="1434205862449" ID="ID_1736858324" MODIFIED="1434205879837" TEXT="Konsequenz: DataCap muß das verstehen"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1434128128869" ID="ID_244966341" MODIFIED="1434128131785" TEXT="Verben">
|
||||
<node CREATED="1434128134508" ID="ID_553361956" MODIFIED="1434128380058" TEXT="ID-Repräs">
|
||||
<arrowlink COLOR="#ff0033" DESTINATION="ID_976705384" ENDARROW="Default" ENDINCLINATION="2;9;" ID="Arrow_ID_1285375088" STARTARROW="Default" STARTINCLINATION="26;-13;"/>
|
||||
<node CREATED="1434128393429" ID="ID_1275202366" MODIFIED="1434128584214" TEXT="muß GenNode sein">
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
<node CREATED="1434128412934" ID="ID_1319614474" MODIFIED="1434128461227" TEXT="Repräs entscheiden">
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node CREATED="1434128438565" ID="ID_913220298" MODIFIED="1434128678545" TEXT="als ID erkennbar">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
heißt: in der Diff-Verarbeitung wird dieser spezielle check verwendet
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<node CREATED="1434128740117" ID="ID_1537979881" MODIFIED="1434128764209" TEXT="spezielles Baumuster"/>
|
||||
<node CREATED="1434128764893" ID="ID_1430586148" MODIFIED="1434128768689" TEXT="Gefahr von clashes"/>
|
||||
<node CREATED="1434128769325" ID="ID_866845827" MODIFIED="1434128777908" TEXT="entscheide">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
<node CREATED="1434128779661" ID="ID_1739097548" MODIFIED="1434128836241" TEXT="marker-ID + string-Payload"/>
|
||||
<node CREATED="1434128917125" ID="ID_392407967" MODIFIED="1434128927937" TEXT=""fehlkonstruierte" ID + prüf-Prädikat"/>
|
||||
<node CREATED="1434128981381" ID="ID_101281763" MODIFIED="1434128988113" TEXT="spezielle Ref-Payload"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1434128446029" ID="ID_1779802587" MODIFIED="1434128654842" TEXT="hash-identisch">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
heißt: wird direkt von standard-equality so behandelt
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<node CREATED="1434128685597" ID="ID_690649535" MODIFIED="1434128705631">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
brauche speziellen Builder,
|
||||
</p>
|
||||
<p>
|
||||
der das so fabriziert
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1434128706589" ID="ID_1001559218" MODIFIED="1434128728613">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
bekomme einen
|
||||
</p>
|
||||
<p>
|
||||
"ungenutzten" DataCap
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<node CREATED="1434128996949" ID="ID_654762061" MODIFIED="1434129237484" TEXT="könnte zur Ref ausgebaut werden">
|
||||
<linktarget COLOR="#00ff33" DESTINATION="ID_654762061" ENDARROW="Default" ENDINCLINATION="457;0;" ID="Arrow_ID_724106052" SOURCE="ID_819452470" STARTARROW="Default" STARTINCLINATION="457;0;"/>
|
||||
</node>
|
||||
<node CREATED="1434130839653" ID="ID_60404225" MODIFIED="1434130915643">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
Idee: <font color="#990033"><b>Ref-GenNode</b></font>
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1434130866693" ID="ID_1402852366" MODIFIED="1434130886826">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
als Ref erkennbar
|
||||
</p>
|
||||
<p>
|
||||
<font size="1">(Prädikat)</font>
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1434130888581" ID="ID_369455584" MODIFIED="1434130912181">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
hash-identische
|
||||
</p>
|
||||
<p>
|
||||
Ziel-ID ableitbar
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1434206472689" ID="ID_561057428" MODIFIED="1434206482829" TEXT="Variant-Subklasse"/>
|
||||
<node CREATED="1434206483657" ID="ID_473311646" MODIFIED="1434206508445" TEXT="Cast auf Rec-Typ prüfen"/>
|
||||
<node CREATED="1434206509201" ID="ID_717222987" MODIFIED="1434206522117" TEXT="nur Ref-Fall zahlt Overhead"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1434129043245" ID="ID_1120430427" MODIFIED="1434129055076" TEXT="brauchen wir einen ref-Typ">
|
||||
<font NAME="SansSerif" SIZE="12"/>
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1434129063053" ID="ID_1242923371" MODIFIED="1434129082821">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<body>
|
||||
<p>
|
||||
Verarbeiten
|
||||
</p>
|
||||
<p>
|
||||
von Teilbäumen
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
<icon BUILTIN="idea"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</map>
|
||||
Loading…
Reference in a new issue