ichthyo/LUMIERA.clone
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Parameters: look for a suitable arrangement of interfaces

Browse source 
While the role of all the relevant interfaces has been determined,
it still remains difficult to establish a sensible relationship.
Which one is the most fundamental interface?

After a lot of mulling, it seems that the `Provision` interface
should be used as foundation, since it describes the very core
of the parameter concept developed here -- even while the actual
form of the operations must be ''somewhat cunningly reversed'',
so that the knowledge regarding the underlying type can be
kept an opaque implementation detail.

The `Domain` interface would then be layered on top, and describes
the capability to transfer values between buffers marked with different
domains (which effectively requires a double-dispatch in the general case).
This commit is contained in:
Fischlurch 2026-08-31 23:17:32 +02:00
parent 3764479ebd
commit 764185eb85
12 changed files with 283 additions and 12 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

3
src/lib/par/disposition.hpp
View file

@ -26,8 +26,8 @@
#define LIB_PAR_DISPOSITION_H #define LIB_PAR_DISPOSITION_H
#include "lib/par/domain.hpp"
#include "lib/par/provision.hpp" #include "lib/par/provision.hpp"
#include "lib/par/param-type.hpp"
namespace lib { namespace lib {
@ -41,6 +41,7 @@ namespace par {
* notation and stored within the Parameter object (as a container). * notation and stored within the Parameter object (as a container).
*/ */
class Disposition class Disposition
: public ParamType
{ {
public: public:
}; };

4
src/lib/par/domain.hpp
View file

@ -37,6 +37,7 @@
#include "lib/meta/typelist.hpp" #include "lib/meta/typelist.hpp"
//#include "lib/meta/typelist-util.hpp" //#include "lib/meta/typelist-util.hpp"
#include "lib/meta/generator.hpp" #include "lib/meta/generator.hpp"
#include "lib/par/provision.hpp"
#include "lib/meta/trait.hpp" #include "lib/meta/trait.hpp"
#include "lib/util.hpp" #include "lib/util.hpp"
@ -53,7 +54,6 @@ namespace par {
using std::numeric_limits; using std::numeric_limits;
struct ValBuff { /*placeholder*/ };
template<typename X> template<typename X>
constexpr inline ValBuff& constexpr inline ValBuff&
@ -109,7 +109,7 @@ namespace par {
,bool ,bool
>; >;
/** build a generic visitor interface for all types in list */ /** build a generic visitor interface for all types in list */
using TypeHandlerInterface = meta::InstantiateForEach<BaseTypes::List, TypeHandler>; using TypeHandlerInterface = meta::InstantiateForEach<BaseTypes::List, TypeHandler, Provision>;
/** /**

4
src/lib/par/param-type.cpp
View file

@ -21,6 +21,7 @@
#include "lib/error.hpp" #include "lib/error.hpp"
#include "lib/par/parameter.hpp" #include "lib/par/parameter.hpp"
#include "lib/par/provision.hpp"
#include "lib/par/param-type.hpp" #include "lib/par/param-type.hpp"
namespace lib { namespace lib {
@ -28,8 +29,7 @@ namespace par {
/* emit VTables in this translation unit... */ /* emit VTables in this translation unit... */
Provision::~Provision() { }
ParamType::~ParamType() { }
Domain::~Domain() { } Domain::~Domain() { }

2
src/lib/par/param-type.hpp
View file

@ -42,9 +42,9 @@ namespace par {
* Furthermore, the interface exposes allowed conversion and conforming operations. * Furthermore, the interface exposes allowed conversion and conforming operations.
*/ */
class ParamType class ParamType
: public Domain
{ {
public: public:
virtual ~ParamType(); ///< this is an interface
}; };

46
src/lib/par/parameter.hpp
View file

@ -43,14 +43,58 @@ namespace par {
class Parameter class Parameter
{ {
public: public:
class Builder;
template<typename VAL> template<typename VAL>
VAL get(); VAL getVal();
template<typename VAL>
void setVal (VAL&&);
/* === Builder API === */
template<typename VAL>
static Builder forType();
protected: protected:
}; };
class Parameter::Builder
{
public:
Parameter
build()
{
UNIMPLEMENTED ("terminal builder operation: package a disposition into the Parameter");
}
};
template<typename VAL>
Parameter::Builder
Parameter::forType()
{
UNIMPLEMENTED ("how to setup the base type configuration? do we need a type parameter in the Builder class?");
}
template<typename VAL>
VAL
Parameter::getVal()
{
UNIMPLEMENTED ("extract the »value«, possibly applying suitable type conversions");
}
template<typename VAL>
void
Parameter::setVal (VAL&& changedVal)
{
UNIMPLEMENTED ("apply suitable type conversions and clamping, then transfer the new value into the Provision interface");
}
}} // namespace lib::par }} // namespace lib::par
#endif /*LIB_PAR_PARAMETER_H*/ #endif /*LIB_PAR_PARAMETER_H*/

16
src/lib/par/provision.hpp
View file

@ -25,12 +25,15 @@
#define LIB_PAR_PROVISION_H #define LIB_PAR_PROVISION_H
#include "lib/par/param-type.hpp" #include "lib/time/timevalue.hpp"
namespace lib { namespace lib {
namespace par { namespace par {
using time::Time;
struct ValBuff { /*placeholder*/ };
/** /**
@ -40,11 +43,22 @@ namespace par {
* and assigned, while the current time-based value is the result of evaluation. * and assigned, while the current time-based value is the result of evaluation.
* Any parameter value is associated to a ParamType that defines the underlying * Any parameter value is associated to a ParamType that defines the underlying
* value domain and possibly a scale with range limits and metric constraints. * value domain and possibly a scale with range limits and metric constraints.
* @remark the value access and manipulation works _backwards_ from an implicit
* value that is conceptually located _within_ this provision towards
* an ValBuff for external access. The reason for this indirect
* formulation is that the »value« is assumed to comply to some data type,
* which however remains an opaque internal detail and is not disclosed.
*/ */
class Provision class Provision
{ {
public: public:
virtual ~Provision(); ///< this is an interface virtual ~Provision(); ///< this is an interface
virtual void retrieveInto (ValBuff&) const { /*NOP*/ }
virtual void pullAt (Time, ValBuff&) const { /*NOP*/ }
virtual void setValFrom (ValBuff const&) { /*NOP*/ }
virtual void connect (Provision&) { /*NOP*/ }
virtual void disconnnect() { /*NOP*/ }
}; };

7
tests/16parameter.tests
View file

@ -7,6 +7,11 @@ return: 0
END END
PLANNED "Parameter Domain Type" ParameterDomain_test << END TEST "Parameter Domain Type" ParameterDomain_test << END
return: 0
END
PLANNED "Parameter Provision" ParameterProvision_test << END
return: 0 return: 0
END END

1
tests/lib/par/parameter-domain-test.cpp
View file

@ -184,6 +184,7 @@ namespace test{
verify_valueAccess() verify_valueAccess()
{ {
BaseDomain<int> domInt; BaseDomain<int> domInt;
SHOW_EXPR(sizeof(BaseDomain<int>)) ///////////////////////////////////////TODO this should be only one »slot«, but is actually quite large, due to using multiple inheritance in the Domain interface. /////OOO fix that!
Domain& dom{domInt}; Domain& dom{domInt};
int val = 1 + rani (1000); int val = 1 + rani (1000);

2
tests/lib/par/parameter-provision-test.cpp
View file

@ -50,7 +50,7 @@ namespace test{
/**************************************************************************//** /**************************************************************************//**
* @test document behaviour of paramter value provision and automation. * @test document behaviour of parameter value provision and automation.
*/ */
class ParameterProvision_test : public Test class ParameterProvision_test : public Test
{ {

8
tests/lib/par/parameter-test.cpp
View file

@ -76,6 +76,14 @@ namespace test{
void void
simpleUsage() simpleUsage()
{ {
Parameter par = Parameter::forType<int>().build();
CHECK (0 == par.getVal<int>());
par.setVal (12.3);
CHECK (12 == par.getVal<int>());
CHECK (12u == par.getVal<uint64_t>());
CHECK (12.0 == par.getVal<double>());
CHECK (true == par.getVal<bool>());
} }

2
tests/lib/several-builder-test.cpp
View file

@ -171,7 +171,7 @@ namespace test{
} }
/** @test various ways to build an populate the container /** @test various ways to build and populate the container
* - with a defined interface type \a I, instances of arbitrary subclasses * - with a defined interface type \a I, instances of arbitrary subclasses
* can be added, assuming there is sufficient pre-allocated buffer space; * can be added, assuming there is sufficient pre-allocated buffer space;
* all these subclass instances are accessed through the common interface. * all these subclass instances are accessed through the common interface.

200
wiki/thinkPad.ichthyo.mm
View file

@ -82647,8 +82647,8 @@
<icon BUILTIN="help"/> <icon BUILTIN="help"/>
<node CREATED="1783087038084" ID="ID_192113507" MODIFIED="1783087050833" TEXT="ein Parameter ist nicht unbedingt ein &#xbb;Value&#xab;"/> <node CREATED="1783087038084" ID="ID_192113507" MODIFIED="1783087050833" TEXT="ein Parameter ist nicht unbedingt ein &#xbb;Value&#xab;"/>
<node CREATED="1783087061644" ID="ID_529127857" MODIFIED="1788013904753" TEXT="Einsicht: Symbolische Repr&#xe4;sentationen liegen oft in einem Zwischenfeld"> <node CREATED="1783087061644" ID="ID_529127857" MODIFIED="1788013904753" TEXT="Einsicht: Symbolische Repr&#xe4;sentationen liegen oft in einem Zwischenfeld">
<linktarget COLOR="#3780d5" DESTINATION="ID_529127857" ENDARROW="Default" ENDINCLINATION="-2605;103;" ID="Arrow_ID_1457907870" SOURCE="ID_936945076" STARTARROW="Default" STARTINCLINATION="-1651;72;"/>
<linktarget COLOR="#3367d0" DESTINATION="ID_529127857" ENDARROW="Default" ENDINCLINATION="-692;29;" ID="Arrow_ID_1675730537" SOURCE="ID_1229358137" STARTARROW="None" STARTINCLINATION="-183;13;"/> <linktarget COLOR="#3367d0" DESTINATION="ID_529127857" ENDARROW="Default" ENDINCLINATION="-692;29;" ID="Arrow_ID_1675730537" SOURCE="ID_1229358137" STARTARROW="None" STARTINCLINATION="-183;13;"/>
<linktarget COLOR="#3780d5" DESTINATION="ID_529127857" ENDARROW="Default" ENDINCLINATION="-2605;103;" ID="Arrow_ID_1457907870" SOURCE="ID_936945076" STARTARROW="Default" STARTINCLINATION="-1651;72;"/>
<node CREATED="1783087081345" ID="ID_909620394" MODIFIED="1783087087812" TEXT="Beispiel: eine M&#xfc;nze"> <node CREATED="1783087081345" ID="ID_909620394" MODIFIED="1783087087812" TEXT="Beispiel: eine M&#xfc;nze">
<node CREATED="1783087094301" ID="ID_1763897712" MODIFIED="1783087102346" TEXT="wir behandeln sie zwar als fungibel"/> <node CREATED="1783087094301" ID="ID_1763897712" MODIFIED="1783087102346" TEXT="wir behandeln sie zwar als fungibel"/>
<node CREATED="1783087105729" ID="ID_167575054" MODIFIED="1783090315462"> <node CREATED="1783087105729" ID="ID_167575054" MODIFIED="1783090315462">
@ -83117,6 +83117,58 @@
</body> </body>
</html></richcontent> </html></richcontent>
</node> </node>
<node BACKGROUND_COLOR="#fafe99" COLOR="#fa002a" CREATED="1788209315295" ID="ID_279904556" MODIFIED="1788210268056" TEXT="VTables bl&#xe4;hen sich auf">
<icon BUILTIN="broken-line"/>
<node CREATED="1788209326125" ID="ID_1531181426" MODIFIED="1788209343878" TEXT="Mix-in &#x27f9; schlie&#xdf;t jedes Sub-Objekt komplett mit ein">
<node CREATED="1788210282924" ID="ID_1520344652" MODIFIED="1788210493326" TEXT="zwar gibt C++ keinerlei Garantien zum Daten-Layout (au&#xdf;er f&#xfc;r PODs)">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
das hei&#223;t, meine ganzen Argumente bzgl &#187;Slots&#171; f&#252;r die VTable sind eigentlich nicht durch den Standard gedeckt; sie sind aber insofern fundiert, da C++ keine <i>Penalty f&#252;r nicht verwendete Features</i>&#160; erlaubt &#8212; und insofern kann es keine Layout-&#187;Optimierung&#171; geben, die die VTable <i>schlechter implementiert</i>&#160;als durch einen einzigen Pointer
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1788210305934" ID="ID_1202028335" MODIFIED="1788211052497" TEXT="jedoch kann man aus der &#xbb;Sub-Objekt&#xab;-Mechanik durchaus Schl&#xfc;sse ziehen">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
Im Einzelnen ausgef&#252;hrt:
</p>
<ul>
<li>
C++ - Code wird auch auf ABI-Ebene strukturiert und zusammengef&#252;gt
</li>
<li>
Eine Basisklasse ist self-contained und wird als Ganzes eingef&#252;gt und referenziert, einschlie&#223;lich ihres Implementierungs-Codes (Ausnahmen k&#246;nnen gelten unter Optimierung, aber nur wenn der Compiler v&#246;llige &#196;quivalenz garantieren kann
</li>
<li>
das bedeutet: der Code der Basis-Klasse bezieht sich auf sein eigenes Layout
</li>
<li>
die virtuellen Methoden werden nicht per ID aufgel&#246;st, sondern komplett in &#187;Slot-Offsets&#171; &#252;bersetzt.
</li>
<li>
wenn also Code einer Basisklasse eine virtuelle Methode aufruft, dann holt er sich seine VTable (die irgendwo im Objekt per Referenz materialisiert sein mu&#223;, was aber auch ein Funktionspointer leisten w&#252;rde). Auf diese VTable wendet der Code einen festen Offset an, und springt durch den resultierenden Funktionspointer.
</li>
<li>
dieser Code wird nicht umgeschrieben, wenn er in ein abgeleitetes Objekt eingebunden ist (abgesehen von Optimierungen, die jedoch niemals garantiert sind)
</li>
</ul>
<p>
<u>Schlu&#223;folgerung</u>: der Code einer Methode der Basisklasse mu&#223; immer das komplette Layout dieser Basisklasse in gleicher Weise vorfinden. Insofern ist es generell nicht m&#246;glich, VTables mehrerer eingemischter Basisklassen zusammenzulegen, ohne auch den kompletten Code der Basisklasse neu generieren zu m&#252;ssen.
</p>
</body>
</html></richcontent>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1788211053578" ID="ID_1121107125" MODIFIED="1788214912904" TEXT="Also &#x27f9; mu&#xdf; doch umstellen auf eine lineare Kette &#x2014; auch f&#xfc;r die Interfaces">
<linktarget COLOR="#f91755" DESTINATION="ID_1121107125" ENDARROW="Default" ENDINCLINATION="-1456;53;" ID="Arrow_ID_1757832686" SOURCE="ID_1738529643" STARTARROW="None" STARTINCLINATION="-304;11;"/>
<icon BUILTIN="yes"/>
</node>
</node>
</node> </node>
</node> </node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1783101484020" ID="ID_1158137372" MODIFIED="1784502236650" TEXT="entwicklen per ParameterDomain_test"> <node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1783101484020" ID="ID_1158137372" MODIFIED="1784502236650" TEXT="entwicklen per ParameterDomain_test">
@ -84252,6 +84304,124 @@
<node CREATED="1788134521733" ID="ID_842811959" MODIFIED="1788134537999" TEXT="das Thema Lifecycle und Updates wird vertagt"/> <node CREATED="1788134521733" ID="ID_842811959" MODIFIED="1788134537999" TEXT="das Thema Lifecycle und Updates wird vertagt"/>
</node> </node>
</node> </node>
<node CREATED="1788206198399" ID="ID_1847444820" MODIFIED="1788206207841" TEXT="Interfaces und Implementierung ordnen">
<node CREATED="1788206230916" ID="ID_1359008095" MODIFIED="1788206243716" TEXT="das Parameter-front-End st&#xfc;tzt sich auf die Disposition ab">
<node CREATED="1788206245531" ID="ID_69324827" MODIFIED="1788206249932" TEXT="auch das ist noch ein Interface"/>
<node CREATED="1788206250703" ID="ID_1870838756" MODIFIED="1788206739527" TEXT="allerdings eine Mischung aus Generics/OO">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...was hier allerdings nur meint, da&#223; auch zus&#228;tzliche normale Funktionen mit Basis-Implementierung bereits da sind, und da&#223; es fest vorgegebene Datenstrukturen gibt, f&#252;r die der Zugriff <i>inline</i>&#160; ist. An der Stelle k&#246;nnte auch die Fallunterscheidung ansetzen f&#252;r einfache Parameter vs. Komplexe Parameter. Dennoch mu&#223; der Disposition-Typ letztlich finit und explizit definiert sein, denn er wird als &#187;Interface&#171;-Typ in einen PolymorphicValue gepackt.
</p>
</body>
</html></richcontent>
</node>
</node>
<node CREATED="1788206814932" ID="ID_1738529643" MODIFIED="1788214912904">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
es mu&#223; <i>zwingend </i>eine lineare Interface-Kette sein mit <i>einer </i>VTable
</p>
</body>
</html></richcontent>
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
das macht den Aufbau tricky, und nicht leicht zu entscheiden, denn alle wichtigen Interfaces m&#252;ssen direkt explizit aufeinander aufbauen; es gibt keine M&#246;glichkeit, variable Aspekte sp&#228;ter <i>einzumischen. </i>
</p>
</body>
</html></richcontent>
<arrowlink COLOR="#f91755" DESTINATION="ID_1121107125" ENDARROW="Default" ENDINCLINATION="-1456;53;" ID="Arrow_ID_1757832686" STARTARROW="None" STARTINCLINATION="-304;11;"/>
</node>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1788207092440" ID="ID_1489003663" MODIFIED="1788214784231" TEXT="Typ und BaseDomain werden zum Problem">
<icon BUILTIN="messagebox_warning"/>
<node CREATED="1788207114186" ID="ID_1160746668" MODIFIED="1788207125545" TEXT="BaseDomain ist bereits ein (generisches) Implementierungs-Objekt"/>
<node CREATED="1788207143449" ID="ID_1569730697" MODIFIED="1788217785702" TEXT="das bedeutet: die Provision kann nicht davon erben, sondern nur vom Domain-Interface">
<arrowlink COLOR="#ff001d" DESTINATION="ID_214321685" ENDARROW="Default" ENDINCLINATION="4;-14;" ID="Arrow_ID_1991058182" STARTARROW="None" STARTINCLINATION="-120;4;"/>
<node BACKGROUND_COLOR="#f8f1cb" COLOR="#a50125" CREATED="1788216306876" ID="ID_1088562291" MODIFIED="1788217074557" TEXT="logischer &#x2b4d; : ein Typ m&#xfc;&#xdf;te damit auch eine Provision sein">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...unter der Vorgabe, da&#223; wir nur eine einzige lineare Vererbungskette haben k&#246;nnen &#10233; da Domain unter Provision liegen mu&#223;, und BaseDomain &#252;ber allen Interfaces, und der Typ von BaseDomain abgeleitet sein soll.
</p>
</body>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
</node>
</node>
<node CREATED="1788207233069" ID="ID_403725711" MODIFIED="1788207254569" TEXT="aber die konkrete Scale mu&#xdf; darauf aufbauen (da sie Werte beschr&#xe4;nkt)"/>
<node CREATED="1788215170120" ID="ID_1317810371" MODIFIED="1788215194280" TEXT="Typ mu&#xdf; konkret sein, schlie&#xdf;t BaseDomain ein und verweist auf Scale"/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1788215427662" ID="ID_214321685" MODIFIED="1788217785702" TEXT="Das Povision-Interface mu&#xdf; anders angeordnet werden">
<linktarget COLOR="#ff001d" DESTINATION="ID_214321685" ENDARROW="Default" ENDINCLINATION="4;-14;" ID="Arrow_ID_1991058182" SOURCE="ID_1569730697" STARTARROW="None" STARTINCLINATION="-120;4;"/>
<icon BUILTIN="yes"/>
<node CREATED="1788215544358" ID="ID_622102416" MODIFIED="1788215569419">
<richcontent TYPE="NODE"><html>
<head/>
<body>
<p>
ich m&#246;chte da&#223; jeder <i>Parameter </i>auch eine Provision <i>sein kann</i>
</p>
</body>
</html></richcontent>
<node CREATED="1788215575560" ID="ID_690071422" MODIFIED="1788215606429" TEXT="das ist das front-End"/>
<node CREATED="1788215613679" ID="ID_200801579" MODIFIED="1788215624951" TEXT="somit wird hier auch eine Interface-Kette eingemischt"/>
<node CREATED="1788215708763" ID="ID_907924223" MODIFIED="1788215727096" TEXT="oder man w&#xfc;rde Zugang zu einer Provision bieten"/>
</node>
<node CREATED="1788215737795" ID="ID_516807030" MODIFIED="1788215749277" TEXT="Provision wird damit ein eigenst&#xe4;ndiges Interface">
<node CREATED="1788215750841" ID="ID_374789197" MODIFIED="1788215911279" TEXT="sie ist nur implizit getypt">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
bedeutet: es wird Kenntnis eines (opaquen) Typs in der Implementierung unterstellt, so da&#223; man Provisions verkn&#252;pfen kann, und sich diese automatisch adaptieren. <i>Aber das Interface selber</i>&#160;bietet keinerlei M&#246;glichkeit, diese implizite Information zu extrahieren (und wenn, dann nur durch ein neutrales Analyse-Pr&#228;dikat, oder Zugang zu einer Domain-Referenz)
</p>
</body>
</html></richcontent>
</node>
<node CREATED="1788217133940" ID="ID_1963209378" MODIFIED="1788217153881" TEXT="das k&#xf6;nnte das Basis-Interface f&#xfc;r alles werden">
<icon BUILTIN="idea"/>
<node CREATED="1788217155932" ID="ID_1701900965" MODIFIED="1788217167793" TEXT="es ist &#xbb;a parameter in a nutshell&#xab;">
<node CREATED="1788217177034" ID="ID_63305825" MODIFIED="1788217183394" TEXT="kann Wert lesen / setzen"/>
<node CREATED="1788217184038" ID="ID_1219385660" MODIFIED="1788217193683" TEXT="kann per Zeit auswerten"/>
<node CREATED="1788217194571" ID="ID_798704416" MODIFIED="1788217205237" TEXT="kann auf Quelle connecten / disconnecten"/>
</node>
<node CREATED="1788217258149" ID="ID_1205932945" MODIFIED="1788217358954" TEXT="(k&#xf6;nnte bei Bedarf ein Domain&amp; hervorzaubern)">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...das w&#252;rde ausnutzen, da&#223; die Implementierung immer oben auf der ganzen Interface-Kette sitzen mu&#223;; somit k&#246;nnte man von jeder konkreten Instanz, die Provision&amp; implementiert, auch schlu&#223;folgern da&#223; sie sich auf eine Domain&amp; downcasten l&#228;&#223;t
</p>
</body>
</html></richcontent>
</node>
</node>
<node CREATED="1788221594093" ID="ID_579519208" MODIFIED="1788221708229" TEXT="es mu&#xdf; aber per default als NOP implementiert sein">
<richcontent TYPE="NOTE"><html>
<head/>
<body>
<p>
...sonst wird es schwierig mit dem Zusammenstellen der Interface-Kette; tats&#228;chlich lassen sich alle f&#252;r dieses Interface vorgesehenen Operationen &#187;leer&#171; Implementieren &#8212; es passiert dann einfach gar nichts, keine Zuweisung, keine Verbindung
</p>
</body>
</html></richcontent>
<icon BUILTIN="messagebox_warning"/>
</node>
</node>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1788222498625" ID="ID_1110945916" MODIFIED="1788222611950" TEXT="Disposition wird dann der Knotenpunkt auf dem die Implementierung aufbaut">
<icon BUILTIN="idea"/>
<node CREATED="1788222535392" ID="ID_1282201343" MODIFIED="1788222543419" TEXT="Disposition ist immer noch ein Interface"/>
<node CREATED="1788222544142" ID="ID_1947215779" MODIFIED="1788222568288" TEXT="es wird per PolymorphicValue auf das Parameter-Objekt exponiert"/>
<node CREATED="1788222571539" ID="ID_1256386409" MODIFIED="1788222603029" TEXT="die ganze konkrete Implementierung setzt darauf auf (und bleibt damit opaque, und variierbar)"/>
</node>
</node>
<node CREATED="1788134884746" ID="ID_195532610" MODIFIED="1788134888546" TEXT="Builder-Notation"> <node CREATED="1788134884746" ID="ID_195532610" MODIFIED="1788134888546" TEXT="Builder-Notation">
<node CREATED="1788134893182" ID="ID_1219540786" MODIFIED="1788134948392" TEXT="naheliegend: statischer Einsteieg vom Parameter-Frontend"> <node CREATED="1788134893182" ID="ID_1219540786" MODIFIED="1788134948392" TEXT="naheliegend: statischer Einsteieg vom Parameter-Frontend">
<node CREATED="1788134968239" ID="ID_217011834" MODIFIED="1788134998930" TEXT="Parameter::from(prototype).build()"/> <node CREATED="1788134968239" ID="ID_217011834" MODIFIED="1788134998930" TEXT="Parameter::from(prototype).build()"/>
@ -84276,6 +84446,34 @@
</node> </node>
</node> </node>
</node> </node>
<node CREATED="1788203329439" ID="ID_1991597342" MODIFIED="1788203340179" TEXT="Parameter-Basisfunktionen">
<node CREATED="1788203369397" ID="ID_1275080112" MODIFIED="1788203381813" TEXT="treibe den Struktur-Aufbau">
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1788203394319" ID="ID_1002785268" MODIFIED="1788203455329" TEXT="Disposition festlegen">
<icon BUILTIN="full-1"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1788203400185" ID="ID_900611719" MODIFIED="1788203458783" TEXT="Builder-Notation schaffen">
<icon BUILTIN="full-2"/>
</node>
<node BACKGROUND_COLOR="#eee5c3" COLOR="#990000" CREATED="1788203422590" ID="ID_1249325546" MODIFIED="1788203462519" TEXT="Valure-Konversionen einbinden">
<icon BUILTIN="full-3"/>
</node>
</node>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1788203353588" ID="ID_810940322" MODIFIED="1788203359142" TEXT="entwicklen per Parameter_test">
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#eef0c5" COLOR="#990000" CREATED="1788203485528" ID="ID_1524876130" MODIFIED="1788203551838" TEXT="simpleUsage">
<icon BUILTIN="pencil"/>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1788203491453" ID="ID_1148834637" MODIFIED="1788203559585" TEXT="einfachen unlimitierten int-Parameter erzeugen">
<icon BUILTIN="flag-pink"/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1788203508251" ID="ID_1482426242" MODIFIED="1788203559586" TEXT="diesem einen (typisierten) Wert zuweisen">
<icon BUILTIN="flag-pink"/>
</node>
<node BACKGROUND_COLOR="#fdfdcf" COLOR="#ff0000" CREATED="1788203517810" ID="ID_473781313" MODIFIED="1788203559587" TEXT="den Wert in verschiedene Typen extrahieren">
<icon BUILTIN="flag-pink"/>
</node>
</node>
</node>
</node>
</node> </node>
</node> </node>
</node> </node>