Invocation: consider how to arrange the InvocationAdapter
- it is clear that this adaptor will be a ''Concept'' - yet it must in some way access the `FeedManifold` and also control additional storage - a rather obvious solution is to layer it ''on top'' of the manifold
This commit is contained in:
parent
ec65e2b7b9
commit
0d7d4b5afa
2 changed files with 171 additions and 41 deletions
|
|
@ -72,6 +72,7 @@
|
|||
//#include "lib/linked-elements.hpp"
|
||||
//#include "lib/util-foreach.hpp"
|
||||
//#include "lib/iter-adapter.hpp"
|
||||
#include "lib/meta/function.hpp"
|
||||
//#include "lib/itertools.hpp"
|
||||
//#include "lib/util.hpp"
|
||||
|
||||
|
|
@ -253,6 +254,24 @@ namespace engine {
|
|||
};
|
||||
/////////////////////////////////////////////////////////////////////////////////////////////////////////////TICKET #1367 : Rebuild the Node Invocation
|
||||
|
||||
/**
|
||||
* Definition to emulate a _Concept_ for the *Invocation Adapter*.
|
||||
* For each Proc-Asset, the corresponding Library Adapter must provide
|
||||
* such adapters to access the input and result buffers and finally to
|
||||
* invoke the processing functions from this library.
|
||||
* - `connect(MAN&,fanIn,fanOut)` access the _Feed Manifold_ and link the buffers
|
||||
* - `invoke()` invoke the processing function, passing the connected buffers
|
||||
* @tparam MAN the concrete type of the Feed Manifold, holding an array with
|
||||
* input and output _Buffer Handles_
|
||||
*/
|
||||
template<class ADA, class MAN>
|
||||
constexpr void
|
||||
_verify_usable_as_InvocationAdapter()
|
||||
{
|
||||
ASSERT_MEMBER_FUNCTOR (&ADA::connect, void(MAN&, uint, uint));
|
||||
ASSERT_MEMBER_FUNCTOR (&ADA::invoke, void());
|
||||
}
|
||||
|
||||
|
||||
struct WeavingPatternBase
|
||||
//////////////////////////////OOO non-copyable? move-only??
|
||||
|
|
@ -267,11 +286,19 @@ namespace engine {
|
|||
};
|
||||
|
||||
|
||||
template<class PAR, uint N>
|
||||
template<uint N, class FUN>
|
||||
struct InvocationAdapter
|
||||
: FeedManifold<N>
|
||||
{
|
||||
FUN process;
|
||||
};
|
||||
|
||||
|
||||
template<class PAR, uint N, class FUN>
|
||||
struct SimpleWeavingPattern
|
||||
: PAR
|
||||
{
|
||||
using Feed = FeedManifold<N>;
|
||||
using Feed = InvocationAdapter<N, FUN>;
|
||||
|
||||
uint fanIn{0};
|
||||
uint fanOut{0};
|
||||
|
|
|
|||
|
|
@ -863,9 +863,7 @@
|
|||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1484865298093" ID="ID_1797078596" MODIFIED="1518487921046">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
die <i>Closure</i> eines Lambdas hängt am Kontext
|
||||
|
|
@ -877,9 +875,7 @@
|
|||
<node CREATED="1484865349366" ID="ID_652410738" MODIFIED="1518487921047" TEXT="betrifft den term-Functor intern"/>
|
||||
<node CREATED="1484865513568" ID="ID_696204655" MODIFIED="1576282358157" TEXT="selbst wenn der Funktor selber per Value übergeben wird">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
konkret:
|
||||
|
|
@ -909,9 +905,7 @@
|
|||
</node>
|
||||
<node CREATED="1484800741349" ID="ID_1156360682" MODIFIED="1518487921047">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Debug: nur <b>ein</b> Element connected
|
||||
|
|
@ -961,9 +955,7 @@
|
|||
<node CREATED="1501791881175" ID="ID_361179647" MODIFIED="1518487921047" TEXT="jede Lösung willkürlich"/>
|
||||
<node CREATED="1501791876032" ID="ID_381137803" MODIFIED="1576282358157" TEXT="logisch unsinnig">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
weil die Abstraktion "UI-Element" eben grade
|
||||
|
|
@ -2321,9 +2313,7 @@
|
|||
<icon BUILTIN="button_ok"/>
|
||||
<node CREATED="1538707420444" ID="ID_334911121" MODIFIED="1538707474258" TEXT="denn nur so erscheint er z.B. bei einem TextView">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
das Widget hat offensichtlich keine eigene graphische Repräsentation.
|
||||
|
|
@ -4034,9 +4024,7 @@
|
|||
</node>
|
||||
<node CREATED="1502375221129" ID="ID_368784036" MODIFIED="1576282358152" TEXT="dies möglich machen...">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
...indem der NotificatonService nun vom UI-Manager gemanaged wird :)
|
||||
|
|
@ -5940,9 +5928,7 @@
|
|||
</node>
|
||||
<node CREATED="1534336069415" ID="ID_1775411301" MODIFIED="1534337958030">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Name: <b>WLink</b>
|
||||
|
|
@ -8282,9 +8268,7 @@
|
|||
</node>
|
||||
<node CREATED="1508540198326" ID="ID_720643889" MODIFIED="1576282358123" TEXT="Konventionen werden nicht verifiziert">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
aber es gibt Konsistenzchecks + Exceptions
|
||||
|
|
@ -11788,9 +11772,7 @@
|
|||
</node>
|
||||
<node CREATED="1513893841787" FOLDED="true" ID="ID_588599089" MODIFIED="1561827469133">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head>
|
||||
|
||||
</head>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
<i>vorläufige</i> MInimal-Lösung
|
||||
|
|
@ -82223,6 +82205,35 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node CREATED="1720058625192" ID="ID_1924296035" MODIFIED="1720058641546" TEXT="dagegen auf Level-2 gibt es nur auf Typ getemplatete Methoden"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1720622058816" ID="ID_187003872" MODIFIED="1720622075685" TEXT="Durchführbarkeit des Level-2-build">
|
||||
<icon BUILTIN="flag-pink"/>
|
||||
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1720622084620" ID="ID_1537828830" MODIFIED="1720622111540" TEXT="alles offen ⟺ Schwachstelle in diesem Design">
|
||||
<icon BUILTIN="messagebox_warning"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720622114808" ID="ID_906665334" MODIFIED="1720622140017" TEXT="muß an einem Lehrbeispiel im Test demonstiert werden">
|
||||
<icon BUILTIN="yes"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1719277220672" ID="ID_605165611" MODIFIED="1720622224666" TEXT="TestRandOntology aufbauen">
|
||||
<arrowlink COLOR="#df3950" DESTINATION="ID_594112005" ENDARROW="Default" ENDINCLINATION="524;-512;" ID="Arrow_ID_839086124" STARTARROW="Default" STARTINCLINATION="-1300;117;"/>
|
||||
<icon BUILTIN="pencil"/>
|
||||
<node CREATED="1720622243718" ID="ID_1592883651" MODIFIED="1720622249510" TEXT="darzustellende Formen">
|
||||
<node CREATED="1720622311005" ID="ID_1329508405" MODIFIED="1720622520282" TEXT="Datenquelle"/>
|
||||
<node CREATED="1720622259404" ID="ID_51699441" MODIFIED="1720622526468" TEXT="lineare Kette"/>
|
||||
<node CREATED="1720622297383" ID="ID_1432254596" MODIFIED="1720622302738" TEXT="in-Place-Processing"/>
|
||||
<node CREATED="1720622349240" ID="ID_1213700731" MODIFIED="1720622362938" TEXT="Mehrkanal-Verbindungen"/>
|
||||
<node CREATED="1720622398314" ID="ID_1820330692" MODIFIED="1720622420325" TEXT="Buffer/Typ-Umwandlungen"/>
|
||||
<node CREATED="1720622422926" ID="ID_712574484" MODIFIED="1720622430129" TEXT="Side-Chain mit anderem Datentyp"/>
|
||||
<node CREATED="1720622435680" ID="ID_1061590842" MODIFIED="1720622446791" TEXT="explizite Verarbeitungsreihenfolge"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720622469696" ID="ID_1611074620" MODIFIED="1720622685878" TEXT="Turnout bauen">
|
||||
<linktarget COLOR="#942459" DESTINATION="ID_1611074620" ENDARROW="Default" ENDINCLINATION="-71;593;" ID="Arrow_ID_1297849942" SOURCE="ID_474766411" STARTARROW="None" STARTINCLINATION="-1091;65;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1720622494997" ID="ID_1991246981" MODIFIED="1720622499456" TEXT="Fallback(NIL)"/>
|
||||
<node CREATED="1720622500356" ID="ID_993801367" MODIFIED="1720622503912" TEXT="einfachste Kette"/>
|
||||
<node CREATED="1720622511356" ID="ID_208964935" MODIFIED="1720622513670" TEXT="Quelle"/>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720314562948" ID="ID_217083278" MODIFIED="1720314731490" TEXT="Daten für Build-Vorgang müssen von separatem Allocator verwaltet werden">
|
||||
<linktarget COLOR="#774459" DESTINATION="ID_217083278" ENDARROW="Default" ENDINCLINATION="-1063;40;" ID="Arrow_ID_711707696" SOURCE="ID_1044694589" STARTARROW="None" STARTINCLINATION="804;73;"/>
|
||||
<icon BUILTIN="yes"/>
|
||||
|
|
@ -86110,6 +86121,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<node CREATED="1719277267208" HGAP="29" ID="ID_594112005" MODIFIED="1719625152303" TEXT="brauche eine komplette Test-Ontologie" VSHIFT="7">
|
||||
<linktarget COLOR="#df3950" DESTINATION="ID_594112005" ENDARROW="Default" ENDINCLINATION="666;-662;" ID="Arrow_ID_801625266" SOURCE="ID_973384222" STARTARROW="None" STARTINCLINATION="-1433;133;"/>
|
||||
<linktarget COLOR="#ff2400" DESTINATION="ID_594112005" ENDARROW="Default" ENDINCLINATION="-136;-44;" ID="Arrow_ID_1657525718" SOURCE="ID_1706482104" STARTARROW="None" STARTINCLINATION="101;9;"/>
|
||||
<linktarget COLOR="#df3950" DESTINATION="ID_594112005" ENDARROW="Default" ENDINCLINATION="524;-512;" ID="Arrow_ID_839086124" SOURCE="ID_605165611" STARTARROW="Default" STARTINCLINATION="-1300;117;"/>
|
||||
<node CREATED="1719277376922" ID="ID_420782384" MODIFIED="1719787483524" TEXT="das ist zugleich ein Prüfstein für das angestrebte »generische Design«">
|
||||
<arrowlink COLOR="#a63b5a" DESTINATION="ID_1834369403" ENDARROW="Default" ENDINCLINATION="-507;-32;" ID="Arrow_ID_249989493" STARTARROW="None" STARTINCLINATION="-211;811;"/>
|
||||
<linktarget COLOR="#412dcd" DESTINATION="ID_420782384" ENDARROW="Default" ENDINCLINATION="131;-411;" ID="Arrow_ID_317368901" SOURCE="ID_746946876" STARTARROW="None" STARTINCLINATION="241;1448;"/>
|
||||
|
|
@ -87759,8 +87771,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
das wäre KISS; man würde den gleichen Template-Parameter N heranziehen, der auch die FeedManifold steuert; dieser wird nach dem Schema »eins«, »zwei«, »viele« belegt. Zusätzlich gibt es für diesen Ansatz dann eine dynamische Spec über die tatsächliche Anzahl der Buffer In/Out (die stets <= N wäre)
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<linktarget COLOR="#504a80" DESTINATION="ID_1917701948" ENDARROW="Default" ENDINCLINATION="-196;10;" ID="Arrow_ID_1275152336" SOURCE="ID_1379190851" STARTARROW="None" STARTINCLINATION="208;0;"/>
|
||||
</node>
|
||||
<node CREATED="1720567844916" ID="ID_1339827409" MODIFIED="1720568335686" TEXT="separat allozierten Buffer vernwenden">
|
||||
|
|
@ -87771,8 +87782,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
Im einfachsten Fall wäre das genauso wie die erste Lösung, nur daß der Buffer nicht im Haupt-Objekt liegt (aber natürlich trotzdem im Allocation-Cluster). Allerdings gäbe es hier noch eine weitere, halb-dynamische Lösung: man würde explizit einen Buffer dynamisch allozieren (direkter Allokator-Aufruf, bei dem man die Anzahl Elemente angibt). Das läuft auf einen minimalistischen Spezial-Container hinaus, oder eine ScopedCollection mit Custom-Allocator, oder dann gleich die nächste Lösung....
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1720567864650" ID="ID_382412515" MODIFIED="1720568417566" TEXT="STL-Container mit custom Alloc verwenden">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
|
|
@ -87782,8 +87792,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
...dies ist mit wenig Entwicklungs-Aufgand umzusetzen, erfordert dann aber trotzdem eine explizite Verdrahtung des Allocators und damit eine Vermischung zwischen Objekt-Konstruktion und Builder/Allocator.
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1720567926106" ID="ID_1451628034" MODIFIED="1720568810548" TEXT="dynamische Descriptor-Liste definieren">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
|
|
@ -87793,8 +87802,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
Unabhängig davon, welche der drei vorgenannten Lösungen zum Zuge kommt, gibt es steths noch eine weitere, komplexere Variante, die aber sehr attraktiv erscheint: es ist nämlich in den weitaus meisten Fällen so, daß nur ein einziger, einheitlicher Buffer-Typ zum Einsatz kommt; daher läuft das Belegen eines Array mit einem expliziten Deskriptor für jeden »Slot« auf erhebliche Speicherverschwendung hinaus. Stattdessen könnte man versucht sein, die Belegung durch ein Stück Code machen zu lassen (eine Closure), und dafür eine Meta-Spec zu interpretieren. Das wird aber in jedem Fell recht komplexer Code, der dann auch zur Render-Zeit läuft (ja wirklich, in jedem Aufruf), und deshalb wieder das Problem aufwirft, woher man die Storage für temporäre Datenstrukturen nimmt. Denn solche wird es zwingend geben, schließlich muß man ja irgendwie markieren, was die <i>bereits behandelten Spezialfälle</i> sind, und welche »Slots« damit übrig bleiben und mit dem Standard-Fall behandelt werden müssen. Ja mei!
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1720569454461" ID="ID_1379190851" MODIFIED="1720569494189" TEXT="fange mit der KISS-Lösung an">
|
||||
|
|
@ -87808,8 +87816,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
diese Lösung ist wohl etwas<i> brachial</i>
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
|
|
@ -87833,8 +87840,7 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
...grundsätzlich besteht diese Möglichkeit, und sie könnte eine gewisse Relevanz bekommen, sobald wir es mit Hardware-Accelleration zu tun haben. Dennoch halte ich das nicht für den Regelfall, und zudem treibt es die Komplexität hoch
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</html></richcontent>
|
||||
<linktarget COLOR="#894a3d" DESTINATION="ID_1659889610" ENDARROW="Default" ENDINCLINATION="531;-27;" ID="Arrow_ID_1852537899" SOURCE="ID_353816206" STARTARROW="None" STARTINCLINATION="675;29;"/>
|
||||
</node>
|
||||
<node CREATED="1720572417472" ID="ID_1892978300" MODIFIED="1720572435945" TEXT="wenn das wirklich nötig wird (YAGNI)..."/>
|
||||
|
|
@ -87850,6 +87856,103 @@ Date:   Thu Apr 20 18:53:17 2023 +0200<br/>
|
|||
<linktarget COLOR="#db4778" DESTINATION="ID_1900172091" ENDARROW="Default" ENDINCLINATION="-567;-19;" ID="Arrow_ID_1645995790" SOURCE="ID_878431324" STARTARROW="None" STARTINCLINATION="-1009;66;"/>
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720622923411" ID="ID_424860567" MODIFIED="1720622943929" TEXT="Rahmen für den InvocationAdapter abstecken">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node CREATED="1720622958532" ID="ID_1033870486" MODIFIED="1720622962842" TEXT="Concept-Operationen">
|
||||
<node CREATED="1720651953015" ID="ID_687895348" MODIFIED="1720651955808" TEXT="connect"/>
|
||||
<node CREATED="1720651956567" ID="ID_52465813" MODIFIED="1720651958422" TEXT="invoke"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#f0d5c5" COLOR="#990033" CREATED="1720651964242" ID="ID_1536301470" MODIFIED="1720651991500" TEXT="wo wird der InvocationAdapter instantiiert?">
|
||||
<icon BUILTIN="help"/>
|
||||
<node CREATED="1720652005776" ID="ID_1482247913" MODIFIED="1720652013585" TEXT="Lösung-1 : fest im Turnout">
|
||||
<node CREATED="1720652026469" ID="ID_181505513" MODIFIED="1720652044111" TEXT="⟹ dann muß er selber stateless sein"/>
|
||||
<node CREATED="1720652044987" ID="ID_398307442" MODIFIED="1720652069203" TEXT="braucht Bewegungsdaten "anderswo" — in der FeedManifold?"/>
|
||||
<node CREATED="1720652077312" ID="ID_1088187170" MODIFIED="1720652121300" TEXT="oder: nur eine einzige Methode (⟹ es ist eigentlich ein Funktor)"/>
|
||||
<node CREATED="1720652631956" ID="ID_829499738" MODIFIED="1720652647664" TEXT="⟹ shed() und weft() fallen zusammen">
|
||||
<icon BUILTIN="smily_bad"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1720652126344" ID="ID_1079595557" MODIFIED="1720652143498" TEXT="Lösung-2 : auf dem Stack">
|
||||
<node CREATED="1720652168706" ID="ID_61021108" MODIFIED="1720652178085" TEXT="dann muß er dort instantiiert werden"/>
|
||||
<node CREATED="1720652904597" ID="ID_1630555344" MODIFIED="1720652921519" TEXT="z.B. von der mount()-Funktion"/>
|
||||
<node CREATED="1720652181026" ID="ID_1177474866" MODIFIED="1720652198764" TEXT="und muß überall hin als Parameter mit durchgereicht werden"/>
|
||||
</node>
|
||||
<node CREATED="1720652297556" ID="ID_99466681" MODIFIED="1720652307387" TEXT="Lösung-3 : in einem speziellen Buffer">
|
||||
<node CREATED="1720652348450" ID="ID_1289118401" MODIFIED="1720652831377" TEXT="würde durchaus gehen (und zwar ohne Indirektion)">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
Die FeedManifold hätte in diesem Fall einen zusätzlichen Platz für ein spezielles BuffHandle. Dieses müßte so konfiguriert werden, daß der Typ des InvocationAdapters und seine Konstruktions-Parameter in dem zugehörigen BufferDescriptor „versteckt“ sind. Trotzdem müßte man dann auch noch für den Aufruf nochmal eine Referenz der FeedManifold an die Funktionen des InvocationAdapters durchgeben
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1720652375738" ID="ID_65844866" MODIFIED="1720652388866" TEXT="wäre allerdings komplexer und hat schlechtere Locality"/>
|
||||
<node CREATED="1720652413489" ID="ID_1011727475" MODIFIED="1720652426947" TEXT="Vorteil: FeedManifold muß seinen Typ nicht kennen"/>
|
||||
</node>
|
||||
<node CREATED="1720652145909" ID="ID_992777691" MODIFIED="1720652296118" TEXT="Lösung-4 : direkt in der FeedManifold">
|
||||
<node CREATED="1720652431967" ID="ID_388052549" MODIFIED="1720652443722" TEXT="FeedManifold wird damit komplexer"/>
|
||||
<node CREATED="1720652447522" ID="ID_1093962097" MODIFIED="1720652581548" TEXT="es kommt zu einer Kombinatorik">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
denn die FeedManifold wird als »eins«, »zwei«, »viele« parametrisiert, und nun kommen hier möglicherweise noch weitere Kombinationen hinzu; ich erwarte allerdings kein volles cartesisiches Produkt, da es i.d.R. einen Zusammenhang gibt zwischen der konkreten Funktion und der Anzahl der Buffer
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
<node CREATED="1720657092672" ID="ID_1327037703" MODIFIED="1720657116940">
|
||||
<richcontent TYPE="NODE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
meine Einschätzung: <i>diese</i> Kombinatorik ist unvermeidbar
|
||||
</p>
|
||||
</body>
|
||||
</html>
|
||||
</richcontent>
|
||||
</node>
|
||||
<node CREATED="1720657118372" ID="ID_963823658" MODIFIED="1720657177004" TEXT="sie wird aber nur voll wirksam in Turnout::weave()"/>
|
||||
</node>
|
||||
</node>
|
||||
<node CREATED="1720657178980" ID="ID_347915086" MODIFIED="1720657888737" TEXT="Lösung-5 : von FeedManifold erben">
|
||||
<linktarget COLOR="#fffddd" DESTINATION="ID_347915086" ENDARROW="Default" ENDINCLINATION="3;42;" ID="Arrow_ID_1339344530" SOURCE="ID_305379370" STARTARROW="None" STARTINCLINATION="-126;5;"/>
|
||||
<icon BUILTIN="forward"/>
|
||||
<node CREATED="1720657208504" ID="ID_1916344427" MODIFIED="1720657315474" TEXT="etwas eleganter da die Parameter-Übergabe wegfällt">
|
||||
<richcontent TYPE="NOTE"><html>
|
||||
<head/>
|
||||
<body>
|
||||
<p>
|
||||
die FeedManifold ist stets fester Bestandteil des InvocationAdapters
|
||||
</p>
|
||||
</body>
|
||||
</html></richcontent>
|
||||
</node>
|
||||
<node CREATED="1720657316762" ID="ID_496227174" MODIFIED="1720657331723" TEXT="macht aber die Anforderungen für den Lib-Adapter komplexer"/>
|
||||
<node CREATED="1720657350412" ID="ID_305379370" MODIFIED="1720657899136" TEXT="man könnte hier aber ggfs auch in ein Baukasten-System einsteigen">
|
||||
<arrowlink COLOR="#fffddd" DESTINATION="ID_347915086" ENDARROW="Default" ENDINCLINATION="3;42;" ID="Arrow_ID_1339344530" STARTARROW="None" STARTINCLINATION="-126;5;"/>
|
||||
<icon BUILTIN="idea"/>
|
||||
<node CREATED="1720657389295" ID="ID_1877085698" MODIFIED="1720657407157" TEXT="eine gewisse Basis-Verdrahtung wird jeder Aufruf brauchen"/>
|
||||
<node CREATED="1720657414308" ID="ID_1844002789" MODIFIED="1720657428934" TEXT="man würde damit gleich auch den Standard-Fall dokumentieren"/>
|
||||
<node CREATED="1720657429677" ID="ID_1435197133" MODIFIED="1720657454373" TEXT="der Lib-Adapter kann aber Spezialisierungen darüber bauen"/>
|
||||
<node CREATED="1720657457921" ID="ID_903330536" MODIFIED="1720657469544" TEXT="oder letztlich doch ganz anders vorgehen (es ist ja generischer Code)"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720620607691" ID="ID_1114186515" MODIFIED="1720620622602" TEXT="diese Invocation nun konfigurierbar machen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1720622579250" ID="ID_474766411" MODIFIED="1720622685877" TEXT="Parameter-Strukturen im Turnout aufbauen">
|
||||
<arrowlink COLOR="#942459" DESTINATION="ID_1611074620" ENDARROW="Default" ENDINCLINATION="-71;593;" ID="Arrow_ID_1297849942" STARTARROW="None" STARTINCLINATION="-1091;65;"/>
|
||||
<icon BUILTIN="pencil"/>
|
||||
</node>
|
||||
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1720622703868" ID="ID_332813706" MODIFIED="1720622709065" TEXT="in Bausteine zerlegen">
|
||||
<icon BUILTIN="flag-yellow"/>
|
||||
</node>
|
||||
</node>
|
||||
</node>
|
||||
|
|
|
|||
Loading…
Reference in a new issue