benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Analysis contd.: even defaultable fields turn out to be problematic

Browse source 
not sure if we're able to maintain the simple line
other than mentioning every field explicitly right away
This commit is contained in:
Fischlurch 2016-05-21 19:06:13 +02:00
parent 72f9b4edb1
commit 021db98b98
2 changed files with 111 additions and 8 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

16
wiki/renderengine.html
View file

@ -1970,9 +1970,9 @@ 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="201506121606" tags="Concepts Model design spec draft" changecount="27">
<div title="ExternalTreeDescription" creator="Ichthyostega" modifier="Ichthyostega" created="201505081647" modified="201605211638" tags="Concepts Model design spec draft" changecount="30">
<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.
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. Yet any formalised, mechanical collaboration requires to represent that common point of attachment -- at least as a 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.
&amp;rarr; TreeDiffFundamentals
&amp;rarr; TreeDiffModel and [[-Implementation|TreeDiffImplementation]]
@ -1983,11 +1983,11 @@ For practical purposes, we have to introduce some distinctions and limitations.
* we have to differentiate the generic node to be either a mere data element, or an object-like ''Record''
* the former, a mere data element, is considered to be &quot;just data&quot;, to be &quot;right here&quot; and without further meta information. You need to know what it is to deal with it.
* 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:
* 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 enumerated; they are considered to be within (and form) the ''scope'' of the given Record (object).
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).
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}}}
@ -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.
</pre>
</div>
<div title="TreeMutatorEvolution" creator="Ichthyostega" modifier="Ichthyostega" created="201603160255" modified="201605192259" tags="Model Concepts design draft" changecount="12">
<div title="TreeMutatorEvolution" creator="Ichthyostega" modifier="Ichthyostega" created="201603160255" modified="201605211648" tags="Model Concepts design draft" changecount="17">
<pre>The TreeMutator is an intermediary to translate a generic structure pattern into heterogeneous local invocation sequences.
!Motivation
@ -8452,10 +8452,10 @@ So we get to choose between
* set up a flexible mapping through a third layer of indirection functors -- which, in a nutshell, is the design choice taken by the TreeMutator
!!!the problem with object fields
Since our goal is to represent changes to structured objects in the form of a diff message sequence, the ability to capture the essence of objects is crucial. We are not concerned with behaviour and state, yet we have to deal with the //object's visible properties.// This gets us into a design dilemma; the notion underlying our diff language is that of //structured data,// which indeed offers the concept of an //attribute// -- but visible properties are based on //object fields,// and thus have more limited capabilities, as being rooted in the class definition behind each object. Consequently our diff language may express changes beyond the abilities of any ordinary object.
Since our goal is to represent changes to structured objects in the form of a diff message sequence, the ability to capture the essence of objects is crucial. We are not concerned with behaviour and state, yet we have to deal with the //object's visible properties.// This gets us into a design dilemma; the notion underlying our diff language is that of //structured data,// which indeed offers the concept of an //attribute// -- but visible properties are based on //object fields,// and thus have more limited capabilities, as being rooted in the class definition underlying each object. Consequently our diff language may express changes beyond the abilities of any ordinary object.
* 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.
-- none of which has any tangible meaning for a regular (language) object. Contrast this with ExternalTreeDescription, which we crafted specifically to support diff language and diff messages, resulting in the ability to represent those changes explicitly. 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 poses 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 &quot;attributes&quot;, especially...
@ -8468,7 +8468,7 @@ Through analysis of the semantics, we could distinguish several flavours of &quo
;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.
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 materialisation 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 by their nature are rather key-value associations arranged in nested scopes.
!!!mapping rules to handle object fields
So we basically ''disallow'' anything related to ''order'', ''re-ordering'' and ''deletion'' of object fields.

103
wiki/thinkPad.ichthyo.mm
View file

@ -3541,6 +3541,109 @@
<node CREATED="1463695640231" ID="ID_176647136" MODIFIED="1463695645090" TEXT="und ist somit nicht unser Problem"/>
</node>
</node>
<node CREATED="1463849505993" HGAP="42" ID="ID_493843802" MODIFIED="1463849535030" VSHIFT="25">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
Dilemma:&#160;<i>defaultable fields</i>
</p>
</body>
</html>
</richcontent>
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1463849536789" ID="ID_864537854" MODIFIED="1463849542928" TEXT="ich m&#xf6;chte sie unterst&#xfc;tzen">
<node CREATED="1463849545196" ID="ID_1187170275" MODIFIED="1463849547316" TEXT="warum">
<icon BUILTIN="help"/>
</node>
</node>
<node CREATED="1463849556474" ID="ID_73579891" MODIFIED="1463849682530" TEXT="Unterst&#xfc;tzung mu&#xdf; konsistent sein">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
....mit der ETD,
</p>
<p>
bzw der Anwendung des selben Diffs auf eine GenNode-Struktur.
</p>
<p>
</p>
<p>
Konsequenz: wenn ein feld <i>defaulted</i>&#160;war, und nun explizit gesetzt wird,
</p>
<p>
mu&#223; dies als INS geschehen, denn eine Zuweisung an nicht aufgef&#252;hrtes Element ist verboten
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1463849716869" ID="ID_712482848" MODIFIED="1463849742347" TEXT="in der Bindung auf ein Objekt habe ich aber keine Attribut-Menge">
<icon BUILTIN="stop-sign"/>
</node>
<node CREATED="1463849761127" ID="ID_865585394" MODIFIED="1463849778956">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
folglich ein Problem,
</p>
<p>
zu erkennen, wenn wir fertig sind
</p>
</body>
</html>
</richcontent>
</node>
<node CREATED="1463849986345" ID="ID_1305704801" MODIFIED="1463849990636" TEXT="genauer...">
<node CREATED="1463850017285" ID="ID_656883117" MODIFIED="1463850033879" TEXT="wenn ein feld zwar gebunden ist"/>
<node CREATED="1463850034699" ID="ID_1531134347" MODIFIED="1463850053756" TEXT="aber bisher keinen Wert bekommen hat"/>
<node CREATED="1463850060359" ID="ID_1083372309" MODIFIED="1463850081800" TEXT="dann darf der Diff es auch nicht per pick auff&#xfc;hren"/>
<node CREATED="1463850086044" ID="ID_1096436471" MODIFIED="1463850099574" TEXT="wenn dann alle mandatory fields behandelt sind"/>
<node CREATED="1463850100634" ID="ID_1329120598" MODIFIED="1463850243005" TEXT="glauben wir, wir sind noch nicht fertig">
<richcontent TYPE="NOTE"><html>
<head>
</head>
<body>
<p>
....weil das defaultable field noch nicht vom Diff ber&#252;hrt wurde.
</p>
<p>
Aber es ist kein optional field, d.h. wir haben keine Flag, die es als &quot;defaulted&quot; kennzeichnet
</p>
</body>
</html>
</richcontent>
</node>
</node>
<node CREATED="1463850138853" ID="ID_1262990387" MODIFIED="1463850143312" TEXT="also ist das Grundproblem">
<node CREATED="1463850144180" ID="ID_103581818" MODIFIED="1463850157454" TEXT="da&#xdf; der TreeMutator global stateless ist"/>
<node CREATED="1463850163257" ID="ID_1219321798" MODIFIED="1463850171716" TEXT="denn er wird immer wieder neu konstruiert"/>
<node CREATED="1463850280082" ID="ID_1381914386" MODIFIED="1463850294324">
<richcontent TYPE="NODE"><html>
<head>
</head>
<body>
<p>
L&#246;sung: <b>alles immer explizit</b>
</p>
</body>
</html>
</richcontent>
<icon BUILTIN="help"/>
</node>
</node>
</node>
</node>
</node>
<node CREATED="1461894614295" ID="ID_1919790561" MODIFIED="1461894618130" TEXT="Bindeglieder">